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ABSTRACT 


The Electronic Waifere Integrated Reprogramming Database (EWIRDB) is the 
p rimar y Department of Defense (DoD) approved source of electronic warfere (EW) data. 
Its utilization in the areas of battle planning and EW research enables our military forces to 
effectively exploit the electromagnetic g)ectrum and shape the outcome of battle. The 
EWIRDB, however, lacks a viable conceptual data model. EWIRDB data are represented 
in digoint parametric tree models that are mplementation-oriented; to the extent that the 
tree structures are used as conceptual modeling tools, their hierarchical form is too 
restrictive to adequately describe EW data semantics. Moreover, these structures address 
only technical parametric data. Associated administrative, reference, and comment data 
are excluded. In practice, the EWIRDB is described in terms of the coded and record- 
based format of its output media, not its conceptual model 

The primary goal of this thesis is the development of a semantically-in:q)roved 
conceptual design of EWIRDB data based on the object-oriented data model (OODM). 
The secondary goal of the thesis is the specification of a logical design, based on the new 
conceptual design, to provide the structure for a subsequent irrplementation of EWIRDB 
data on the Multimodel and Multilingual Database System (M^DBS) in the Laboratory for 
Database Systems Research at the Naval Postgraduate School 

The results of the work contained herem are: (1) an object-oriented conceptual 
design of EWIRDB data that supports the semantics of both the file format and tree 
structures, and (2) the specification of an object-oriented logical design for an M^DBS 
ircplementation of sairqple EWIRDB data. 
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I. INTRODUCTION 


Iq this thesis, I propose an object-oriented design for a rqpresaitative portion of 
the Electronic Warfere Integrated Reprogramming Database (EWIRDB). In this chapter, 
I hi ghlight the inq)ortant role of the EWIRDB in the national defense and provide a 
description of the current format of the database. I conclude with ^ecific thesis 
objectives and an outline for the organization of the theas. 

A. AN OVERVIEW OF THE EWIRDB 

Advances in electronic warfare (EW) technology have had tremendous i]iq)act on 
modem military operations. The application of electromagnetic energy to secmre friendly 
use of the electromagnetic spectrum, and to detect, reduce, or prevent its hostile use may 
well be the decisive factor in the outcome of battle. A force that effectively utilizes the 
electromagnetic spectrum gains the initiative. A force that exploits the weaknesses in an 
adversary’s EW systems renders the adversary blind to the actual tactical situation. 
Success in EW is a prelude to victory. Failure in EW is militarily devastating. 

In the context of today’s electronically-dependent warfare, frequent data collection 
and analysis is essential to the development of EW technologies to counter the enemy 
threat. Efficient maintenance of the latest data, obtained directly from measurement, or 
indirectly via electronic intelligence (ELINT), is the basis of successful EW. The National 
Air fritelligence Center (NAIC) maintains the latest data, in-depth and specific, on EW 
systems of the United States, friendly forces, and non-friendly forces. These data are 
stored in the Electronic War&re Integrated Reprogranmnng Database (EWIRDB). 

“The EWIRDB is the primary Department of Defense (DoD) approved source for 
technical parametric and performance data on noncommunications emitters and associated 
systems.”[1] Noncommunications emitters include radars, jammers, navigational aids, 
transponders, target-sensing systems, and others. AH such emitters generate and receive 
electromagnetic radiation and may be used to gain the advantage in armed conflict. 
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EWIRDB emitter data are therefore indispensable in the analysis and execution of EW; 
without them, our ability to effectively manipulate the electromagnetic spectrum would be 
coit 5 )romised. 

The EWIRDB is the union of data from three constituent sources. The National 
Security Agency (NSA) contributes data from its “BCilting” database. Obtained throng 
ELINT, Kilting data are referred to as observed data in the EWIRDB. Observed data 
result from the direct measurement and analysis of an emitter’s electromagnetic signature 
following the signal intercept; they are fundamental in describing an emitter’s 
performance. The Scientific and Technical Intelligence (S&TI) community, under the 
jurisdiction of the Defense Intelligence Agency (DIA), contributes parametric data 
assessments to the EWIRDB. S&TI systems analysts consider aU available sources of 
information and then estimate or derive the total operational capability of an emitter. 
Derived parametric data in the EWIRDB are referred to as assessed data. The United 
States Noncommimications Systems Database (USNCSDB), supported by the Air Force 
Information Warfare Center (AFIWC), holds data on US owned and operated 
noncommunications emitters. USNCSDB service analysts provide inputs based on 
evaluation of system specifications. EWIRDB data of this type take the same format as 
assessed data, and for this reason, are generally referred to as assessed data as weU. 

The EWIRDB is thus a data composite. Moreover, this pooling of EW data may 
reflect different data values from different sources. Figure 1 depicts the EWIRDB as a 
composite of its three contributory sources. 

Developed in the seventies to support the reprogramming of EW systems, the 
EWIRDB and its role has since grown in both scope and in significance. While its primary 
focus remains in EW software reprogramming, the EWIRDB has become vital in other 
areas: EW research, development, test, and evaluation (RTD&E); modeling and 
simulation (M&S); training and acquisition. Merits of the EWIRDB are revealed by post- 
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Desert-Storm figures: the value of the reprogrammable EW equipment directly supported 
by the EWIRDB has been estimated at $30 billion; the value of the operational systems, 
RTD&E, M&S, and training and acquisition programs that employ the EWIRDB has been 
estimated to be $1 trillion [1], 

In short, the EWIRDB is an indispeusable tool that helps to bridge the gap 
between data analysis and effective exploitation of the electromagnetic environment by 
EW systems. It is a medium whose use ultimately helps maintain mflitary readiness and 
minimize the loss of life in combat. 

B. THE FORMAT OF THE EWIRDB 

Altb migb effective in its ircplementation, the data model of the EWIRDB is 
problematic. The EWIRDB is described in terms of a data-in:q)lementation model to the 
exclusion of a legitimate semantic data model Data is presented in a hierarchical tree that 
is inherently arbitrary and reliant on the use of reference codes to link related pieces of 
data throughout the hierarchy. The non-intuitive hierarchical organization and coding 
scheme prevent the user from gaining a meaningful view of an emitter’s performance 
parameters. Consequently, the nature and semantics of the EW data are obscured by its 
ciuToit representation. 

The administrative information maintained for emitter systems and their associated 
parametric data entries is excluded from the existing data model. The administrative data 
are addressed only in terms of the fi>rmatting of the data output file. This is a major 
shortcoming; the administrative data are inoportant to the analysis and tracking of 
par ame tric data, and represents a significant portion of the database. 

In general, the “intuitiveness” of data representations and the ease with wliich data 
formats may be interpreted largely determine the usefulness of a database. The current 
EWIRDB oversteps the boundaries of both criteria. So while it remains the foremost 
source of mission-critical EW data, lack of an adequate semantic data model ultimately 
results m a reduction of the EWTRDB’s effectiveness as an instrument of EW. 
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1. The Parametric Tree Model 

The upper-level hierarchical data model of the EWBRDB is illustrated in Figures 2 
and 3. The Pulsed/Continuous Wave (P/CW) tree in Figure 2 is used principally to 
evaluate and identify the electromagnetic energy radiated by emitters. The Receiver 
Parametric Performance (RPA) tree in Figure 3 contains receiver design and performance 
information on the receiver portion of emitter systems and serves as a vital reference in the 
development of electronic countermeasures (ECM) techniques and systems. The P/CW 
and RPA trees together provide a comprehensive report on an emitter’s performance . A 
third hierarchical structure, the Electronic Countermeasures (ECM) tree, exists; it is not 
shown in any figure. ECM tree data describe jamming systems, and are referenced in the 
development of electronic counter-countermeasures (ECCM) to overcome the jammer 
threat. At present, however, the viability of the ECM tree is being reevaluated by the 
agencies that partic^ate in and contribute to the EWIRDB program The ECM tree is 
therefore not addressed in this thesis. 

a. The Parametric Tree Structure and Notation 

As depicted in Figures 2 and 3, the tree structures graphically diow how 
emitter data are catalogued. “The tree is a management tool that orders a long list 
logically and hierarchically in a way that proceeds firom broad characteristics through 
levels of successively finer characteristics” [1]. Each branch contains a heading or label to 
indicate the type of parameters or attributes associated with the branch. For exanq)le, 
“SIGNAL POWER” of the 11 B (B) SIGNAL POWER branch in Figure 2 is a branch 
name or heading. Branches contaiu zero or more parameters. A branch with zero 
subordinate parameters is referred to as a “superheader”. Superheader branches pose a 
unique modeling problem - they contain no data and are not reflected in the data contained 
within the database. However, superheaders are usefiil, despite their lack of parametric 
data, in identifying a major areas of interest to be deconposed in subordinate branches. 
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10 B (A) GENERAL INFORMATION 


11 B (B) SIGNAL POWER 


1 B P/CWTREE 


:12 B ANTENNA 



1211 B (C) TX ANTENNA POLARIZATION 

121 B ANTENNA POLARIZATION 

1212 B (D) RX ANTENNA POLARIZATION 


1213 B (E)TX/RX ANTENNA POLARIZATION 


1221 B (F) TRANSMIT ONLY ANTENNA 

122 B ANT CHARACTERISTICS 

1222 B (0) RECEIVE ONLY ANTENNA 


1223 B (H) antenna POLARIZATION 


1311 B (I) PULSED SIGNAL SHAPE (AM) 



131 B PULSEDSIGNAL 

1312 B (J) PRI/PGRI 

13123 B (K> MULTIPLE PULSE GROUPS 



13131 B (L) RFUNE STRUCTURE 








13 B FREQUENCY AND 


1313 B FREQUENCY j 

13132 B (M) PULSED RF 




MODULATION CHAR 


1321 B (P) CW FREQUENCY 



132 B CW 





1322 B (0) CWMODULATION 



14 B (R) ASSOCIATED SIGNALS/SYSTEMS 










Thus, in a parametric tree, branches categorize emitter and signal 
parameters, whereas parameters hold actual data values in the database. A numbering 
system is also provided for describing branching throughout the depth of the parametric 
tree. The branch number is given as the first entry on a branch. Each branch has a single 
predecessor and is assigned a unique number to define a unique path from the root of the 
tree to any given branch. The “11” of the 11 B (B) SIGNAL POWER branch in Figure 2 
is an example of a branch number. 

As q)ecified by branch markers called subfile codes, data are organized 
throughout the tree to effect logical groupings of parameters. Subfile codes appear in 
parentheses in Figures 2 and 3. Data subhierarchies rooted at subfiOle-coded branches are 
meant to encapsulate major aspects of an emitter’s performance or convey the semantics 
of high-level emitter and signal characteristics: Subfiles are therefore equivalent to 
subtrees, and accentuate major groupings of related data. The “(B)” listed on the 11 B 
(B) SIGNAL POWER branch in Figure 2 indicates that subfile B, rooted at branch 11, 
contains data that in the composite is descriptive of the hi^-level characteristic “SIGNAL 
POWER”. 

All branches and parameters in the EWIRDB are not apphcable to all 
database users. A branch or subordinate parameter may be usefiil to an S&TI analyst, for 
instance, and meaningless to Kilting analyst. Likewise, the data in a particular branch may 
be apphcable to all users. Parametric trees contain usage codes to distinguish usability of 
branches and parameters among participating agencies. The non-parenthesized “B” on the 
11 B (B) SIGNAL POWER branch, for example, indicates that the SIGNAL POWER 
branch is used for Kilting, S&TI, USNCSDB, and NSRL (National SIGINT Requirements 
List) purposes. In other words, that branch is apphcable to ah agencies that use the 
EWIRDB. The other codes are K for Khting and NSRL usage, E for S&TI assessed data 
and USNCSDB, and N for NSRL-only usage. 

The hierarchy depicted in Figure 4 offers perspective on the complexity of 
the parametric tree. Specificahy, ah branches subordinate to branch 121 B ANTENNA 
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121X11 B2 LINEAR POLARIZATION 


1211 B TX ANTENNA POLARIZATION 


121 B ANTENNA POLARIZATION 

1212 B RX ANTENNA POLARIZATION 


1213 B TX/RX ANTENNA POLARIZATION 


121X1 B2 FIXED POLARIZATION 

.10 B 4 TIME TO SWITCH MILLISEC 

.20 B 4 AUTO OR MANUAL SWITCHING (TEXT) 


i 121X2 B 2 VARIABLE POLARIZATION 


.10 B1 MAJOR AXIS TILT ANGLE DEG/HOR 

.20 B 6 AXIAL RATIO DB 


121X12 B2 CIRCULAR OR ELLIPTICAL 


.10 B 2 SENSE (LH-RH) 

.20 B 5 AXIAL RATIO 

.3 0 B 2 MAJOR AXIS TILT ANGLE (ELLIPSE) 

(TEXT) 

DB 

121X21 B 2 ADAPTIVE POLARIZATION 


.01 B 2 CHANGE PATTERN 

.10 B 2 RATE OF CHANGE 

.20 B 2 REASON FOR CHANGE 

(TEXT) 

HERTZ 

(TEXT) 

121X22 B 2 MANUAL POLARIZATION CHANGE 

.10 B 2 RATE OF CHANGE 

.20 B 2 REASON FOR CHANGE 

HERTZ 

(TEXT) 

121X23 B 2 PERIODIC PROGRAMMED POLARIZATION 

.10B3 RATE OF CHANGE 

.20 B 4 CHANGE PATTERN 

HERTZ 

CTEXT) 

121X24 B 3 POLARIZATION MODULATION 



.10 B 5 COhTIlNUOUSmiSCREIEPOLARIZA'nONCrEXr) 


.20 B 4 MODULATTNO WAVEFORM OR CODE (TEXT) 
.3 0 B 4 MODULATING RATE MHZ 

.40 B 4 NBR OF DISCRETE POLARIZATIONS INTEGER 
.50 B 5 BIT LENGTH MICROSEC 

.60 B 5 NBR OF BITS DSTTEGER 


121X3 B 2 CROSS POLARIZATION CHAR 
.10 B 3 PATTERN PEAK OFKCT DEGREES 
.20 B 5 PATTERN PEAK RESPONSE DB 


Figure 4 . A Detailed Portion of the P/CW Tree 
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POLARIZATION in the P/CW tree, that is all parameters associated with the branch, are 
revealed. This portion of the parametric tree is neither the most complex nor the most 
populated, but it is a precise and representative sanq)ling of the data that reside in the 
lower levels of the parametric tree. 

The new notation in Figure 4 requires a brief explanation. A parameter is 
listed with a two digit decimal number as a means to differentiate between parameters in a 
given branch. (Branches themselves include the decimal notation, “.00”, but the notation is 
implicit and not shown in the tree model.) The combination of the branch number and the 
two-digit decimal number is referred to as the parametric number. Thus, locating a 
parameter within the tree or w ithin an output data file is a straightforward function of 
indexing into the data via the parametric number. For exanq)le, parametric number 
121X1.10 indexes to the parameter .10 B 4 TIME TO SWITCH under the 121X1 B 2 
FIXED POLARIZATION branch in Figure 4. (The X in the branch number is a variable 
that specifies the type of antenna being considered, i.e., transmit, receive, or transmit and 
receive. The variable takes on the value 1, 2, or 3, accordingly.) 

Additionally, since each parameter contains data, each includes an entry for 
units of measure. Branches, in contrast, are not data entries but rather indicate that 
parametric data groupings may be identified by a branch name or number, and therefore 
do not specify units of measure. 

b. The Limitations of Hierarchical Data Modeling 

In general, the hierarchical data modeling of the EWIRDB parametric trees 
is misleading in its representation of parametric data. Aside firom highli^ting the 
con 5 )lexity of the EWIRDB parametric tree, the sanq)le hierarchy in Figure 4 also e?q)oses 
the arbitrary nature of the trees’ hierarchical structure. An inability to precisely represent 
data semantics is common to generic tree structures such as those of the EWIRDB. The 
current EWIRDB tree model is strapped with this inherent arbitrary quality that limits the 
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EWIRDB’s eflfectiveness as a database and places the burden of data interpretation on the 
user. 

Specifically, the parallel branches, 121X1 B 2 FIXED POLARIZATION, 
121X2 B 2 VARIABLE POLARIZATION, and 121X3 B 2 CROSS 
POLARIZATION CHAR, seem to indicate that for a given antenna, polarization is 
either fixed or variable or exhibits cross polarization characteristics. This is not actually 
the case. For a given antenna, polarization is either fixed or variable, and all antennas may 
be described by cross polarization characteristics. Whereas the fixed and variable 
polarization branches determine a clear boundary based on fimdamental differences in an 
antenna’s characteristics, the cross polarization branch is applicable to all antennas, 
regardless of their differences. The hierarchical structure in Figure 4 does not convey this 
idea. It provides only a generic and inadequate treatment of the intended data semantics. 

A CTttiilaT situation arises in the hierarchy rooted at branch 121X2 B 2 
VARIABLE POLARIZATION in Figure 4. The arbitrary nature of the hierarchical 
modeling structure depicts a variably polarized antenna that appears to be rigged as one of 
Jfour types: adaptive, manually changed, periodic programmed, or modulated. Again, this 
does not accurately reflect the intended meaning of the data. The correct interpretation is 
that a given variably polarized antenna can be described as one of three types: adaptive, 
manually changed, or periodic programmed. And just as the cross polarization branch 
appHed to any given entry in the preceding antenna polarization branch, the polarization 
modulation branch describes characteristics common to all variably polarized antennas. 
The polarization modulation is therefore not a criteria by vriiich to categorize types of 
variable polarization. 

Another flaw in the EWIRDB tree model is a collateral effect of the general 
layout of the data. Parametric data is scattered over a large number of separate records 
corrqrrising two distinct and largely independent structures, the P/CW and RPA trees. A 
search of these two distinct structures and their associated parameters is required to 
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ascertain the performance of a given emitter. Consequently, the global view of an 
emitter’s performance, from a modeling perspective, is obscured. 

Deficiencies in the parametric tree model are further exacerbated by the 
fact that the trees are designed to characterize only parametric data. The EWIRDB also 
contains administrative, reference, and commentary information, all associated with 
parametric data. At best, then, even if the trees were perfect parametric data modeling 
tools, only a portion of EWIR data would have been taken into account. 

The data not included in the parametric tree are loosely modeled in terms 
of a file structure. The file structure is not, however, a data model. It is a descr^tion of 
the data as presented in the output form. Parametric data is therefore also described in 
terms of the output format. While the file “model” incorporates all aspects of the 
database, the overall semantic picture is difficult to grasp; the file format is also complex 
and disjoint. 

2. The File Structure of the Output Data 

The EWIRDB output file format is designed to provide a con 5 )rehensive view pf 
parametric and associated data for emitters. It is cryptic in presentation, however, and 
does not compensate for the lack of a semantically correct data model While the view of 
an emitter’s parametric and associated data in the output file is complete, it is non- 
intuitive. The Technical ELINT Reference File format (TERF) is the standard distribution 
format for the EWIRDB and is composed of six different types of records, referred to as 
logical information records. The record types are q)ecified as follows, with the record 
name preceding the record type designator in parentheses: Classification Record (SOO), 
Emitter Name Record (SOI), Subfile Header (S02), Parametric Data (SOS), 
Reference Data (S04), and Comments (SOS) [1]. 

A brief description of the TERF data fields is required to bridge the gap between 
the data as modeled in the parametric trees and the data as presented in the TERF output. 
Because the EWIRDB consists of data merged from different sources (see Figure 1), some 
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fields are source-specific. A tabular summary of the parametric data and other types of 
data m the output file is provided in Figure 5. In the figure, “assessed data only” refers to 
both S&n and USNCSDB contributed data, as stated earlier in Section LA. A full 
description of the TERF format, including the actual ‘look” of an output file, is given in 
[ 1 ]. 

Three fields do not appear in Figure 5 but are common to all records in a file. The 
first is Record Type, which iq)ecifies the record as SOO, SOI, S02, S03, S04, or SOS. The 
second field is the Source Designator, v^diich identifies the contributory source of the data 
contained in that record; K for Kilting, E for S&TT assessed data, and U for USNCSDB. 
The third field is Notation, which provides the ELNOT (ELINT Notation) assigned to the 
given emitter. The ELNOT is an administrative label that uniquely identifies an emitter. 

Overall, the TERF format is complex. It represents a merger of data from different 
sources with different needs and provides for nonstandard, source-specific data formats. 
The TERF contains many codes. Some codes differ in symbology but relate to identical 
coirq)onaats, and some apply to only certain types of data. Other codes distinguish 
between multq)le versions of the same parameter, and some relate mutually dependent 
parameter values. Mode combinations and the suffix table pose a particularly challenging 
modeling problem While modal relationships are critical in the identification and 
evaluation of emitters, the relationidiips as coded in the suffix table are difficult to grasp, 
especially if emitter modes number in the hundreds of thousands. (Suffix codes are given 
more detailed treatment in Chapter LV). 

Many TERF fields exist solely to link information in one portion of the file to 
information in another segment of the file. The coding and linking picture grows more 
nomplev within the following context. A TERF consists of emitter data partitioned into 
subfiles represented in the S02 records. Each contributory source (Kilting, S&TI 
Assessed, USNCSDB) may supply many different subfiles for a given emitter, each may 
supply muh^le veraons of the same subfile, and sources may overlap in the subfiles they 
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RECORD i RECORD NAME 

i arTERF FIELD 


DESCRIPTION 


Classification I one SOO per emitter 


overall classification of emitter file 


Kilting only, data of data extraction from NSA database 



Emitter Name 


Emitter Name 


S&nCode 


SAE Code 


Multiple Source 
Review Date 


Date of Last 
Si gnif icant Chang 
Parametric Update 
Date 


one SOI per contributory source (KJE, 


name commonlj^ as soc iat e d wit h the ELN OT 
assessed data only; 4 character code that identifies the 
aggicy r esp o nsibl e for th e EL NOT 
Kilting only; 4 diaracter code that idaitifies the agency 
responsible for the ELNOT 


assessed data only, date of the last full review of the 
assessed data file for a given emitter 


Kilting only, date of last full review of the Kilting data 
file for a gi ve n em i tter 

date of most recait diange to any SOS, S04, or 805 
record 




Subfile Header 

one S02 per parametric data subfile per contributory j 
source; multiple S02 records likely 

Subfile Tree 
Number 

subfile-coded brandi number 

Subfile Name 

name (heading) of the subfile-coded branch 

Subfile Code 

1 or 2 character code daioting the subfile or subtree 

Technical Date 

Kilting only, date of last diange in any SOS record 



Parametric Data 

one to many S03 records per parametric data entry 
per contributory source; multiple S03 records likely 

Tree Number 

also called parametric number; index into parametric tree i 

Suffix Code 

1 or 2 character code assigned to help describe emitter 
modes; helps differaitiate between multiple entries for 
the same tree number; links related (dqiaident) 
parameters 

\ Measurement Name 

corresponds to brandi/parameter name in parametric tree j 

1 Units 

corresponds to units spedfied for parameters in 
parametric tree; for textual data, the format may be 
spedfied here 

i Lower/Upper Value 
or Text 

actual parametric data; for numeric data, lower/ii^iper 
value is filled in (with same values if data is single¬ 
valued) 


F^ure 5. A Description of TERF Elements (continued into next page) 
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1 RECORD 

RECORD ?<4ME 
atTBRF FtELI> 

DESCRIPTION^ 

SOS 

cont’d 

Confidence Level 

assessed data only; specifies the analyst’s confidence in 
the parametric data 


S&TI Code 

assessed data only; 3 character code that idaitifies the 
agaicy responsible for the ELNOT 


Reference Number 

links SOS to a reference (S04); 4 character code that 
refers to a line in an S04; 1®* character in code denotes 
the data source, R=Kilting, A=S&TI Assessed, 
F=USNCSDB (differs from SOlcode) 


Comment Number 

code that refers to a line in an SOS; T* character in code 
denotes the data source; C=Kilting, K=S&’n Assessed, 
N=USNCSDB (differs from SOI and Reference Number 
codes) 


Reserve Mode 

code to indicate that the value of the parametric data, or 
mode, is a wartime reserve mode (WARM); also 
indicates analyst’s confidaice in this assessment 


Classification 

assessed data only; 

U=nmclassified,C=confidaitial,S=secret, or T=top secret 


Releasability 

assessed data only; 2 diaracter code designating the 
countries to which the data is releasable 


Date of Last 

1 Update 

date the last significant change was made to the data 


Measurement 

Accuracy 

Kilting only; + or - range if available, used with 

1 numerical parametric data 


Measurement 
Accuracy Units 

Kilting only; same as the units field unless the accuracy 
is so fine it cannot be expressed the same way 


Intelligence Source 

Kilting only; 1 diaracter code, daiotes type of source 
used to derive parametric data (ex. ELESTT, non-ELINT) 


Preferential Rating 

Kilting only; one digit code to signify the relative 
importance of the data, the importance of obtaining the 
data 




S04 

Reference Data 

zero to many S04 records per source per emitter file; 
required if a reference was specified in an S03 record; 
provides a trace back to original source documents 


Reference Number 

same as those specified in the SOS records 


Reference Line 
Number 

sequential and contiguous; many lines of text may be 
required to describe a referaice for a givai referaice 
number 


Figure 5 cont’d. A Description of TERF Elements (cont’d into next page) 
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RECORD 

RECORD NAME 
i : t^rTERFFJELl} 

DESCRIPTION 

804 

cont’d 

Reference Text 

• assessed data format: textual description of the 
parametric data referaice followed by a formatted 
classification/releasability line (refers to the S04) 

• Kilting format: referaice text or document 
number (document title), report date, producer, 
classification of the r^ort 

S05 

Comments 

zero to many S05 records per parametric data item 
per source; required if a comment was specified in 
an S03; suffix table stored in “comment zero”; 
general emitter comments stored in “comment 
one” 


Comment Number 

same as those in SOS records 


Comment Line 
Number 

sequential and contiguous; many lines of text may be 
required to describe a commoit for a given comment 
number 


Comment Text 

used to explain, describe, elaborate, and qualify 
parametric data entries and modes 
• assessed data format: includes a formatted 

classification line for every comment; at least one 
classification line is required for eadi comment 


F^ure 5 cont’d. A Description of T£RF Elements 
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supply to the EWIRDB. Each subfile in turn may consist of many different parametric 
data entries, and there may be many data entries for the same parameter as represented in 
the SOS records. Finally, where applicable, parametric data links to source-specific 
reference documentation and comments in the S04 and S05 records, respectively. And for 
a given emitter, each source may require many S04 and 805 records. The effect of the 
data merge, codes, and links with this framework is an elaborate and burdensome 
presentation of parametric and associated data. 

3. Summary 

The EWIRDB represents a chall^iging database modelmg problem The problem 
stems jfrom several fectors, the foremost of vdiich is the inherent conq)lexity of the data. 
Capturing the nature of EW systems and rignals is difficult. 

Additionally, the parametric trees, the semantic basis of the EWIRDB, have been 
designed and used primarily for database management, not as data modeling tools. To the 
exteut that the trees have beeu used to model parametric data, their hierarchical and 
int rinsic ally arbitrary structure has proven too restrictive to accurately capture the 
semantics of the data. The database us«r is therefore required to logically determine the 
tme nature of the data, if the need for mterpretation is recognized at aU. 

Further, TERF-formatted EWIRDB output provides a coroprehensive view of 
emitter data, but does not fill the semantic gap. While it incorporates the structure of the 
parametric tree model and catalogues associated reference and commentary data, it cannot 
be construed as a data model. Moreover, the TERF format introduces extras into the 
data, such as reference codes, to link related pieces of information. The use of codes 
throughout the file muddles the meaning of the data. 

Finally, without system-supported semantics, the burden of EWIR data 
interpretation is transferred to the user. This is not an easy tadc for the user; the EWIRDB 
is difficult to conprehend because the nature and relationshps of EW data are not 
adequately modeled and are subject to coding. Because the EWIRDB is generally 
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described in terms of data in:]{)lementation and not data semantics, there exists a 
requirement for the development of a more meaningful, iatuitive, and system-supported 
design. The recent advance in object-oriented data modeling indicates that the object- 
oriented alternative may prove useful in sin^lifying and clarifying the data semantics, 
relationidiips, and formats of the EWIRDB. 

C. THESIS OBJECTIVES 

The primary objective of this thesis is to provide a new object-oriented design for a 
sanq)le portion of the EWIRDB. NAIC has identified the EWIRDB for our 
experimentation in object-oriented database design. The object-oriented data model is 
arguably the most semantically rich and flexible of all database design tools. The 
effectiveness of the object-oriented data model, however, remains untested for any military 
or warfere-related deagn of the scope of the EWIRDB. 

The secondary objective is to use the object-oriented data definition language (O- 
ODDL) as a design tool for the q)ecification of the object-oriented EWIRDB. At present, 
the O-ODDL used in this thesis is the product of a larger thesis effort that produced an 
object-oriented interfece to the Multimodel and Multilingual Database System (M^DBS) 
[7] at the Naval Postgraduate School (NPS). The O-ODDL specification of a new 
EWIRDB deagn is therefore a continuation of the NPS research. It will ultimately provide 
an on-line object-oriented EWIRDB wi th which to demonstrate both the utility of the new 
M^DBS object-oriented interfece, and the usefulness of the new object-oriented EWIRDB 
design. 

D. THE ORGANIZATION OF THE THESIS 

In Chapter n of the thesis, I address basic issues in the object-oriented database 
development, within the context of conceptual design and logical design processes, hi 
Chapter HI, I provide the design mechanisms of the object-oriented data model. In 
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Chapter IV, I further describe the tools of the proposed object-oriented design and present 
the conceptual design of the EWIRDB. In Chapter V, I briefly describe the logical design 
structures native to the M^DBS and present the logical design. In Chapter VI, I 
summarize my assessment of the new object-oriented EWIRDB. 
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n. DESIGN CONCEPTS 


Database design is a mult^base process. Each phase addresses a different aspect 
of the design process and yields a separate design result or model The partitioning of the 
design process in this way guarantees the viability of each design phase as a distinct entity. 
Moreover, it sinq)lifies the entire process, because the corcplexity of the design problem is 
also partitioned. Only certain aspects of the design need be addressed in each phase, and 
the designer is e?qposed to the details of a given level only. The correct and thorough 
design of one phase lends itself to the development of a subsequent phase. 

In this chapter I addresses those aspects of database design that are central to this 
thesis: the conceptual design and the logical design. These are the first phases in the 
overall design process and are therefore elemental to the overall design. Together, the 
conceptual and logical design phases take a proposed database fi’om abstraction to 
implementable form 

The treatment here is generic; design mechanisms specific to object-oriented 
database design are examined in Chapter IQ. 

A. THE CONCEPTUAL DESIGN 

Much like an architect’s sketch crystallizes the customer’s architectural design 
vision, the conceptual design captures the nature of data in a way that closely resembles 
the database users’ perception of data and the usage of data. 

The fundamoatal goal of conceptual database design is thorou^ understanding of 
the database throu^ development of a conceptual schema. A tool known as the high- 
level data model, also referred to as a semantic or conceptual data model, is used. A 
high-level data model is intuitive, flexible, and con[q)rehensive hi its description of data. It 
is the means by v^ch a schema is developed to approximate the users’ perception and 
usage of the proposed database. To this end, the set of abstraction concepts underlying 
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the semantic data model are sufficiently expressive of data, single in nature, unambiguous, 
mininial in number, and nonoverlapping in meaning [2]. 

Devised within the framework of the high-level data model, the conceptual schema 
thus characterizes the structure of data. The structure of the data is the sum and 
substance of the database, enconq)assing data types, data relationships, and data 
constraints. Since the conceptual design should be intuitive, its design notation is typically 
associated with a diagrammatic rq)resentation of its modeling constructs. A diagram is a 
simple, precise, high-level, and straightforward means of ejq)ressing the nature of data. 

An essential quality of a conceptual schema is that it be independent of a specific 
database management ^stem (DBMS). A DBMS-independent semantic data model is 
generic and free of any limit ation or peculiarity inq)osed by a particular DBMS. 
Consequently, the details of data implementation and physical data storage are suppressed 
in the conceptual schema. Such detail is not useful in the development of a high-level 
conceptual design. Accordingly, the conceptual schema cannot be used directly to 
implement the database. This, however, is not disadvantageous. Rather, it highlights the 
impmtance of the conceptual design and the value of the conceptual schema as a stable 
description of the database. A stable database description - file conceptual schema - 
r emains unaltered by any modification to the underlying DBMS-dependent logical and 
phyacal designs. 

As the initial phase in the design effort, conceptual design is paramount in database 
development; the entire process depends on the creation of a stable and correct conceptual 
schema. 

B. THE LOGICAL DESIGN 

The architect’s initial sketch, like the conceptual schema, is the foundation for all 
subsequent design work. After capturing the essence of the customer’s desires in the 
sketch, the architect then addresses the ^edfics of the design layout. Decisions are made 


20 



based on the enviromnent and the available materials. The outcome is a blueprint, a 
q)ecification for the construction of the design. 

As the blueprint follows the sketch, the logical design in database development 
follows the conceptual design. The logical design likewise yields a “blueprint” of the 
conceptual schema that accounts for the type of database system in which the database 
will reside. 

The logical design is equivalent to a mapping from conceptual schema to the data 
model of the selected DBMS. The mapping is acconq)lished by the designer via the 
DBMS’s native data definition language (DDL); the output DDL statements are 
equivalent to a DBMS-readable specification of the conceptual schema. The end result of 
logical design is thus a transformation of the database as proposed in the conceptual 
design to a database in the DBMS-con3patible form for eventual realization in the DBMS. 
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m. OBJECT-ORIENTED DESIGN CONCEPTS 


Conceptual design and logical design, as described in Chapter n, cast the 
foundation of database development; a high-level data model provides the mechanisms 
required to formulate these designs. Thus, both design processes proceed within the 
framework of the chosen data model. The data model is therefore the starting pomt. 

The definitive measure of a data model’s effectiveness is it abstraction capability, 
or the degree to AAdiich its design mechanisms capture “real-world” semantics. Traditional 
data models, including the hierarchical model, are limited A^dth respect to their abstraction 
capabihties. The EWIRDB hierarchical model is a prime exan^le; and as detailed in 
Chapter I, the model is fimdamentally deficient in its representation of EWIR data. For 
traditional data models in general, tire more conq)lex the nature of the data, the greater the 
semantic mismatch between the real-world data and its representation. 

Object-oriented database design, a departure from traditional methods, seeks to 
eliminate the semantic mismatch between real-world entities and their database 
representations. The object-oriented data model (OODM) is the basis of the design 
effort. The OODM is more semantically rich than the earlier models. Object-orientation 
more closely parallels the way we observe the real-world. We are surrormded by objects: 
conq)uters, cars, roads, buildings, trees, people, animals, the atmo^here - the list of 
objects is hifinite. People tend to reason about real-world “objects” in terms of their 
characteristics, both static and dynamic. A car, for kstance, might be classified by its 
make, model, and year, as well as by its performance in various drivhig conditions. We 
also tend to apply different degrees of abstraction to the real-world entities that we 
encounter. Depending on a person’s point of view, a real-world “object” may be looked 
upon as a single, indivisible unit, or as the conq)osite of a number of conq)onent objects. 
Returning to the car exanq}le, the typical car owner probably takes the view that a car is 
an integral unit that provides a means of tran^ortation. A car mechanic, on the other 
hand, probably sees a car as the sum of its parts - parts that require maintenance and 
replacement. The object-oriented approach is a close approximation to these human views 


23 



of the world. It is for this reason that object-oriented abstraction techniques are generally 
considered to be more powerful than those of the traditional data models. 

The OODM thus provides the design mechanisms with "vAbich to model diverse and 
sophisticated applications in a natural way. In a larger sense, within the context of overall 
database development, the object-oriaited approach reflects a move toward an 
“intelligent” DBMS that directly supports advanced data modeling. Li such a system, 
semantic correctness remains intact from abstraction to in^lementation. The burden of 
translation is lifted from the user. 

The object-oriented paradigm remains the focus of the active research. While 
researchers and developers agree on the underlying piinc^les, the exact nature and 
direction of the object-oriented approach is at present an issue of debate. Consequently, a 
final and irrefiitable definition for the OODM has not yet been forwarded. Despite the 
evohitionaiy condition of the OODM, the motivation to preserve a direct correspondence 
between real-world entities and their database representations warrants its use. The 
EWIRDB is an ideal candidate for object-oriented modeling. 

In this chapter, I present the bade concepts of the OODM. Because the OODM 
was developed with the ease of iiiq)lementation in mind, some implementation issues are 
also briefly addressed. These concepts lay the groundwork for an application of the 
OODM, within the context of both conceptual and logical design, to a representative 
portion of EWIRDB data in Chapter IV. 

A. OBJECTS 

The object is the basic element of the OODM, and the conq)onent that populates 
the database. An object corresponds to any entity in the real world: ideas, concepts, 
people, events, places, physical stractures, and time to name a few. The uniform 
application of objects to model the spectrum of real-world aitities surplifies flie designer’s 
view of the real world [4] and infuses some consistency into the designer’s task. 
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Li an object-oriented database management ^stem (OODBMS), an object is 
specified with a unique, system-generated marker called the object identifier (OID). The 
OID is immutable, or permanent and unchangeable [2]. This is an in^ortant aspect of the 
OODM from a modeling and in^lementation point of view. The use of OID’s effectively 
decouples the object existence from the object value. An objects can therefore be 
referenced via the OID, indq)endent of an identifying value. Two objects with different 
OID’s remain distinct, even if the two objects have the same values. In traditional models, 
on the other hand, the identities of data items are vahie-based. The cumbersome task of 
creating and managing unique identifiers (called keys traditionally) is therefore imposed on 
the application programmer. Consequently, meaningful keys are likely long and non¬ 
unique, and the management of key values is carried out external to the DBMS. The 
effect is a degradation in database performance. 

The hierarchical model of the EWIRDB is vahie-based and therefore subject to 
these shortcomings. Specifically, data items referenced by application programs steer 
through an identification scheme that includes the ELNOT and a burdensome hierarchical 
labeling network. For a given ELNOT, or equivalently for a given emitter, a data record 
is uniquely identified by a sufBx code/tree number/source combination [1]. In an object- 
oriented EWIRDB, a data object is uniquely identified by a system-maintained OID. 

The OODM also provides for the creation of objects of arbitrary conqilexity [2]. 
The internal structure of objects is thus sufficiently adaptable to include all significant 
information that describes an entity. This internal structure is referred to as the object’s 
state and behavior [3]. These a^ects of the OODM are addressed in the following 
sections. 

1. Object State 

An object is characterized by internal properties generally referred to as attributes. 
The values of an object’s attributes define the state of the object. Attribute values may 
either be simple or complex. 
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a. Simple Attributes 

Simple attributes are those w^iose values are literals - character strings, 
integers, floating-point numbers, and other primitive values. Typically, literals are not 
considered as objects. For efficiency reasons, they are usually represented directly or are 
self-identifying, and not associated with OID’s [4]. 

b. Complex Attributes and Relationships 

Complex attributes are those whose values are conq)osed of other objects 
or groupings of values. There are three kinds of conoplex attributes: reference attributes, 
collection attributes, and derived attributes [4]. The first two types provide for an 
arbitrarily deep or recursive nesting of objects, where the state of an object is described by 
attributes whose values are objects whose values may be objects as well, and so on. A 
nat ural representation, then, for the state of an object is a set of OID’s of the objects that 
are the values of the attributes of the object [3]. 

Reference attributes are the means by which relationships between entities 
are represented in the OODM. In taking on object values, reference attributes e?q)Hcitly 
refer to, or draw a relationship to, other entities. Specifically, in the logical design, 
reference attributes may be used to model binary and non-binary one-to-one, one-to-many, 
and many-to-many relationsh^s. A relationship may be modeled in one direction, such as 
fi:om an object A to an object B, where object A refers to object B but object B contains 
no such reference to object A, or in both directions throu^ the use the of an inverse 
reference or irtverse attribute [2]. An inverse reference fecihtates traversal of the 
relationship. The relationsh^ is “visible” to each object; object A refers to object B and 
object B refers to object A inversely. All the relationships in which a particular object type 
participates are thus packaged within the object itself in the form of reference attributes. 
In contrast, a conq)lete inspection of the parametric trees and TERF output may be 
required to ascertain the relationships that exist between particular parametric entities in 
the EWIRDB. 
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la iiiq)leiuentation, reference attributes provide an additional benefit. They 
cannot be corrupted, ie. inadvertently or maliciously changed: the integrity of 
relationships and references is maintained by the OODBMS throughout all database 
operations. Moreover, firom a modeling perfective, because a reference attribute refers 
to an OBD and not a value, the values encapsulated within the object to which the 
refer«ice attribute points may be changed with no effect on the OID, and thus no effect to 
the reference attribute. [4] The use of reference attribute has one possible shortcoming, 
however. Beyond meaningful reference attribute names, references in the OODM do not 
imply any special semantics. Basically, references can only convey the idea of an 
association between entities. 

Collection attributes encoitfass those characteristics of an object that are 
described by more than one value, or present a couf lex arrangement of values. These 
values are stored in constructors such as lists, sets, or arrays. The value sets, or domains, 
from which the values comprising the collection are taken may contain anf le values or 
references. For example, a collection attribute may be a set of integers or a list of entities 
that participate in a relationshf with the object. 

Object properties that are subject to frequent or regular modifications, such 
as those that are time-based or date-based, are best modeled with derived attributes. 
Derived attributes, as the name inflies, are not stored explicitly. Rather, they are defined 
via the execution of a particular procedure. A given value for a derived attribute, and 
therefore its storage, is teuf orary in nature. 

Except for the brief introduction to derived attributes, the discussion of 
object state to this point has dealt with the static characteristics, or structure of an object. 
The next section addresses object characteristics that are dynamic in nature. 

2. Object Behavior and Encapsulation 

An inf ortant aspect of the OODM is its ability to incorporate the operations to be 
applied to an object of a certain type into the object itself The procedures that modify or 
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return the state of an object in an OODBMS are called methods. The behavior of an 
object is thus defined by the methods specified to act on it. 

Methods are much like programs. They are written in a typical programming 
language. A method consists of two parts: an external interface (or signature) and the 
actual code to im plement the method. The external interfece defines the parameters 
whereby an object interaction is recognized. It is the only legal means by vsMch to invoke 
the method. Typically, the execution of a method is accon: 5 )lished via the message 
passing [2]. if, for exanq)le, an object A sends a properly-parameterized message to an 
object B in order to invoke a method in object B that returns the data stored in object B, 
then the method of object B would return the data to requesting object A. This concept of 
restricting access or providing well-defined access to an object is referred to as 
encapsulation. If strict encapsulation is enforced, thai the object itself - its internal 
structure and methods - is accessible only via the specified parameters. The only “user- 
visible” portion of the object is the external interfiice; the data contained within the object 
and file details of the method’s inq)lementation are conqiletely hidden firom external users. 
Procedures that are visible outside the object are public methods. An object may also 
encapsulate private methods, or those available only to the object itself In practice, 
however, strict object encapsulation is too restrictive in any OODBMS [4]. In addition to 
file public methods, attributes may be made visible as well 

Encapsulation is a basic tenet in the OODM. Its benefit is straightforward: 
encapsulation permits a change in the implementation of objects without forcing any 
change in the external programs that use them As long as external interfeces remain the 
same, the means to access and man^ulate objects remain the same. Provided the external 
interface r emains intact, it follows that objects vriiose structure has been modified will 
appear unchanged to the external world. Encapsulation is also mq)ortant in introducing 
the concept of object class. 
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B. OBJECT CLASSES 


A database generally contains clusters of simila r objects. Each cluster contains 
objects that encapsulate the same structure and behavior, or attributes and methods. Just 
as an abstract data type is the specification for a number of data structures in a typical 
program, a class in the OODM is the specification for a number of similar objects in a 
database. A database containing multiple clusters of similar objects would therefore be 
comprised of several classes. And just as identically-formatted data structures may 
contain different stored values, objects of similar structure and behavior, or objects in the 
same class, may exhibit different states. 

These ideas are illustrated in Figure 6 >^hich represents a small portion of data 
maintained in a fictitious database at NFS. The THESIS class definition provides the 
blueprint for creation of THESIS objects. This definition specifies three smq)le attributes 
- title, author, and date of publication - and two methods - author bio and number 
distributed. The method author bio returns the author’s branch of service and war&e 
specialty (data stored elsewhere in the fictitious database). The method number 
distributed returns for a given thesis the number of copies distributed, a value that may be 
subject to periodic change. The class THESIS is void of any actual data, but the objects 
of class THESIS contain values for each q)ecified attribute and invoked method. These 
attribute and method values differ from object to object; each object of class THESIS 
therefore exhibits a different state. 

Classes are the basic building blocks of the object-oriented modeling. The concept 
of class is therefore the basis of fimdamental modeling mechanisms in the OODM. These 
modeling mechanisms are the focus of this section. Some of these mechanisms are 
considered to be core concepts in the model The semantica]ly-m 5 )ortant is-instance-of 
relationsh^ is one. The concept of gemralization-zhA.- specialization is another. Less- 
widely-acknowledged object-oriented modeling concepts of aggregation and covering are 
addressed as well 
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CLASS DEFINITION 


THESIS 


attributes; 
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Figure 6. An Object Oass and its Objects 
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In addition to its value in the data modeling, the class concept has in:q)oitant and 
fevorable consequences in implementation. When viewed as the collections of their 
instances rather than as the specifications of individual objects, classes form the logical 
basis for the formulation of queries [5]. Further, because attribute and method 
q)ecifications co mmo n to objects of the same class are stored as a class object, there is no 
need to repUcate the co mmo n information in each object of the class. The effect has 
considerable savings in storage space. Finally, the class concept provides a degree of 
“type checking” throu^out a class composition hierarchy [3]. The class conq>osition 
hierarchy is the direct result of the recursive nesting of objects as attribute values, an idea 
introduced in section in.A.l.b. These objects are restricted in their values by then- 
respective class specifications. In this sense, the class is analogous to the traditional 
notion of attribute domain. Just as the domain defines legal values or types for a given 
attribute, the class defines the legal values for a particular object of that class. The class 
thus provides a degree of type checking for an attribute whose value is an object. 

With the OODM concepts of the object and the class as building blocks, the 
following sections detail the design abstractions applied to the proposed object-oriented 
design of EWIRDB data. 

1. Instantiation and Classification 

The class itself is an object, void of actual data. Thus, it is also termed the class 
schema. It fimctions as the “blueprint” with vriiich to generate objects of the same class. 
Viewed in this li^t, an object based on the blueprint of a given class can be thought of as 
an instance or an occurrence of that class. Since a class contains the definition of a set of 
objects, it is also an abstraction mechanism [5]. The class abstraction is rooted in the 
complementary semantic modeling concepts of instantiation and the classification 

The instantiation is the process of creating objects widiin the parameters of a given 
class schema. Classification is the inverse of instantiation. It is a process of systematically 
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as signing objects of similar structure and behavior to their respective object classes. 
Classification permits the modeling of co mmo n characteristics that apply to all of the 
objects in the class. 

Because its a single blueprint from which many objects may be created and 
catalogued, the class structure may be reused as required to instantiate many similar 
objects. In Figure 6, the blueprint for the class I'MESIS is used three times to instantiate 
each of the three THESIS objects shown. For this reason, iustantiation and clas^cation 
are collectivefy considered to be the first reusability mechanism of object-oriented design. 
Inheritance, addressed in the next section, is the second such mechanism 

2. Generalization and Specialization 

Inheritance among classes produces class hierarchies that characterize the OODM 
abstraction concepts of the generalization and the specialization. In an inheritance 
hierarchy, a class referred to as the subclass inherits the structure and behavior of another 
class called the superclass. In addition to its inherited characteristics, the subclass may 
encapsulate attributes and/or methods not contained in the superclass. These distinct . 
additions to the subclass differentiate it fiom the superclass and identify the subclass as 
worthy of a class status all its own. In the hierarchy, a subclass is viewed as a 
q)ecialization of its superclass. Likewise, a superclass can be perceived as the 
generalization of those subclasses (from one to many) participating in the inheritance 
hierarchy. Collectively, the concepts of generalization and socialization are equivalent to 
the is-a-kind-of relationship. If an indq)endent and unique subclass XI inherits the 
attributes and methods of a superclass X, then XI may be considered “a kind of’ X. 

A data hierarchy based on the inheritance is natural and well-defined, unlike 
hierarchies based on arbitrary and coded tree structures, such as those found in the 
EWIRDB. Inheritance enshasizes both the commonality and the uniqueness among 
classes. Moreover, the inq)lementation of an inheritance (ie., a generalization and a 
Socialization) as a mapping from class to another class eliminates data duplication and 
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localizes the management of common data. It is for this last reason that inheritance is 
touted the second reusability mechanism of object-oriented design. 

3. Aggregation 

The aggregation abstraction considers a con^osite object as the sum of its parts. 
It is not restricted to an object as an aggregation of its attributes. The term is primarily 
meant to represent an object as an aggregation of other objects, ie., a con^osite object as 
the sum of its conq)onent objects. The semantics are coirqparable to those of the is-a-part- 
of relationship, where an entity is the grouping of its coix^onents. 

The objects of component classes partic^ating in the aggregation each have their 
own state. Likewise, each object of the con^osite class exhibits its own state. But the 
state of the corq)osite object in a given aggregation is dependent upon the states of its 
conq)onent objects. A coirposhe object thus contains a “global” type of structure and 
behavior that reflects the conq)osite state of its con:q)onent parts. 

Singly drawing a relationship between an object and its aggregates is not 
semantically suffident; it does not capture the dependency between the con:q)Osite object 
and its conqionents. From an inq)lementation point of view, a relationsh^ will not 
maintain the integrity of the aggregation, or the interactions within the aggregation, 
throughout all possible database operations. In particular, an operation on the conq)osite 
object should affect component objects. Conversely, an operation on a conq)onent object 
should affect the con:q)Osite object. The deletion of a conq>osite object, for exan^le, 
should cause deletion of all coroponents of the object. The aggregation and the notion of 
a composite object can also be used as the basis for the clustering of data [4]. 

The aggregation abstraction is an inq)ortant semantic concept in the OODM. It is 
a design concept not found in other models. 
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4. Covering 

The covering abstraction is accepted as a fundamental concept in the OODM 
vvithin the European community. It adds a dimenaon of flexibility in the modeling and 
manipulation of data. The covering terminology is as followsi class X covers class Y if 
every object in class X corresponds to a subset of objects in class Y. These subsets of Y 
need not partition Y; they are certain subsets of all the subsets generated for the objects of 
Y. Mathematically, all the subsets of Y form the power set of Y, ie., P(Y). The 
correspondence is a mapping f v4iich determines for an object, x, firom class X all the 
objects, y’s, of the subset f(x) fi:om class Y, such that J9^x) = y for every one of those y’s 
Class X is referred to as the cover class and class Y is called the member class. [6] 

A covering relationship thus corresponds an object of one class to a subset of the 
power set (the set of all subsets) of objects of another object class. It is therefore an 
object-to-object-set mapping. 

A single and practical exarcj^le involving a team and its players is useftd in 
describing the covering relationship between two classes. In this example, the team class 
covers the player class. The team’s existence is entirely dependent on the partic^ation of 
its players, a type of existence dependency. While a team object has its own structure and 
behavior, its real value is derived firom its encapsulation of the nature of a particular set of 
players that corrprise the team. Further, a team object may be operated on as a single 
object or as a set of player objects. And as is generally the case in the real-world, the 
ehmination of a team (object) does not necessarily entail the demise of its players. 

The covering is a valuable abstraction mechanism, specific to the OODM, that 
accurately models entities of the real world. 
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IV. A CONCEPTUAL OBJECT-ORIENTED EWIRDB 


Li this chapter, I apply the princ^les of the OODM, as presented in Chapter m, to 
develop a genuine concq)tual design for the EWIRDB. My intent is not to redefine the 
kinds of data required to characterize an emitter’s performance; the existing EWIRDB 
data herns have sound scientific roots. Nor do I atten[q)t to address every existing data 
element in the EWIRDB. My goal is to justify the proposhion that the object-oriented 
approach is feasible for the EWIRDB by providing a conceptual design of a representative 
portion of the database - a portion that adequately reflects the nature of electronic warfere 
data. Diagrams are used at every stage to codify flie conceptual design. A description of 
the conceptual dedgn symbology must first be addressed. 

The absence of a standardized OODM introduces some variation in its 
diagr ammat ic representation. However, most of the ^rmbology adopted in this thesis for 
the conceptual deagn of the EWIRDB is commonly used. Pos^le exceptions are those 
notations corresponding to abstractions such as covering and aggregation. Variations 
aside, the consistent use of an adequately-expressive symbology is all that matters. 

The symbology used in the conceptual design of the EWIRDB are drown in Figure 
7. The inherhance abstraction as h appears in Figure 7 includes some detail not previously 
addressed. The concept of overlapping iriheritance stipulates that an object of the 
superclass (generalization class) may be a member of more than one subclass of the 
specialization. Disjoint inheritance states that an object of the superclass may be a 
member of at most one subclass of the specialization. Regardless of the type, however, 
each inheritance hierarchy in the conceptual design of the EWIRDB is a total 
specialization. This idea states that every object of a superclass must be a member of 
some subclass in the given inheritance hierarchy[2]. 
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The representation of relation^ps requires anq)]ification as well. Figure 7 
includes a description of the participation constraints in relationships between the objects 
of partic^ating classes. A total participation constraint indicates that for the class of 
objects whose participation in a given relationsh^ is total, the very existence of that class 
of objects depends on its participation in the relationsh^. For exaiiq)le, in a relationship 
between co mmo n entities such as tran^ortation vehicles and license plates, the 
participation of license plates would be total; hcense plates are unnecessary if there are no 
vehicles to license. Ergo, the existence of license plates depends on tiie relationship 
between cars and license plates. A partial participation constraint, in contrast, states that 
all objects of a particular class need not participate in a given relationship. In a 
relationship between married couples and children, for instance, not all married couples 
have children. The participation of married couples in the relationship is therefore partiaL 
Participation constraints are an important aspect of conceptual modeling. They fiuther 
characterize the nature of data relationsh^s. 

A. A GLOBAL SCHEMA 

The EWIRDB was described earlier (Figure 1) as the adnunistrative merging of 
data from three contributory sources. Now, a global and object-oriented view of the 
merged structure of the EWIRDB is provided in Figure 8 with the use of aggregation 
semantics. The ‘big picture” object-oriented view of the EWIRDB in Figure 8 is largely 
administrative. It may at first seem strange to proceed hi this manner, to initially approach 
the modeling task from an administrative rather than technical point of view, especially in 
li^t of the technical nature of emitter data. But this approach is valid. As explained in 
Chapter 1, the data items that describe an emitter retain the formatting particular to the 
database from vdiich they were contributed. In a global view, source-specific groupings 
of data herns are assigned group-specific administrative labels. A design that proceeds 
within an administrative context preserves these inq)ortant associations. 
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Figure 8. The Conceptual Schema: A Global View 
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As a result of the merging, the data items contributed by each source to describe a 
particular emitter may overlap. Moreover, each source may contribute mult^le value 
entries for a ^en data item But the identity of each data entry remains intact. Multiple 
entries for a given data item are not “fused” together to form a single EWIRDB entry. 
Each data item remains separate and distinct, in a form that is suggestive of its source. 
Approaching the conceptual design from an administrative bias thus ensures that the 
overall structure of the database as a collection of emitter data from mult^le sources will 
be accurately reflected in the object-oriented schema. 

In Figure 8, the aggregates KILTING EMITTER, S&H EMITTER, and 
USNCSDB EMITTER combine to form the con:Q)osite EMITTER class of objects. 
This aggregation precisely models the multi-source stracture of the database. As the 
conqposite, an EMITTER object represents the merging of all data for a given emitter. 
Each aggregate, on the other hand, represents a source-^edfic portion of the data in the 
conjposite. The aggregate KILTING EMITTER encapsulates Kilting technical data 
contributed to the EWIRDB for a given emitter. The S&TI EMITTER aggregate 
encapsulates the technical data contributed from S&TI centers, and the USNCSDB 
EMITTER aggregate encapsulates USNCSDB data for a given emitter. 

With aggregation semantics, emitter parametric data may be reasoned about on 
two levels of abstraction; in the conq)osite, dealing with all available data, or on the 
aggregate (conq)onent) level, where the data from a particular contributory source is 
considered singularly. This adds a degree of flexibility in the manipulation of data that 
may not be achievable in more conventional models. Further, categorizing emitter data by 
source is appropriate because it allows the drawing of relationships between source- 
^ecific administrative data and the aggregates themselves. In Figure 8, each aggregate 
participates in a 1:1 relationship with an administrative-data class of objects; KILTING 
EMTITER with KILTING ADMINISTRATIVE DATA; S&Tl EMITTER with 
S&TI ADMINISTRATIVE DATA; and USNCSDB EMITTER with USNCSDB 
ADMINISTRATTVE DATA. The partic^ation of each administrative data class in its 
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respective 1:1 relationsih^ is total because the existence of an administrative data class 
depends solely on the viability of the relationship. for instance, the Kilting database 

contributed no data to the EWIRDB for a given emitter, then for that given emitter, the 
KILTING EMIITER class of objects would be undefined. In effect, KILTING 
EMITTER would be non-existent, as would any relationdi^ in which it participated. In 
this example, the existence of the KILTING ADMINISTRATIVE DATA class of 
objects would be meaningless as well 

As mentioned in Chapter I, the formatting for S&TI and USNCSDB data are the 
same. The attributes in the related administrative data classes are also the same. The 
attribute values, however, are likely different between the two classes. This does not rule 
out the possibility that some or all of the values may be identical. But the possibility, 
likely or not, that the attribute values may differ depending on the source necessitates the 
appearance of the same attributes in both classes. For the same reason, the attributes 
classiRcation and releasability are duplicated in all three administrative data classes. 
This seems to contradict object-orientation, wherein commonality is fectored out among 
gimilar classes to form a superclass. However, because the attribute values may possibly 
be different fi'om class to class, the common attributes, by virtue of their values, still 
fimction to differentiate the classes, bi these particular situations, the semantics of 
generalization sinqrly do not apply and the same attribute values may appear in each class. 

The EWIRDB ADMINISTRATIVE DATA class contains methods to extract 
information firom the source-specific classes in the schema. These methods retrieve 
administrative data for a given emitter that in turn define the administrative state of all 
merged emitter data. An object of the class EWIRDB ADMINISTRATIVE DATA may 
reflect data retrieved fi:om more than one class of the schema. The method overall 
classification returns the hipest classification firom among the source-specific 
administrative data classes; it defines the classification or the conq)osite classification for a 
given emitter. Altb migb not at present an attribute e?q)licitly accounted for in the 
EWIRDB, the method overall releasability was included to satisfy the requirement that 
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“...The releasability and handling caveats reflect a merger of the three sources... ”[1] This 
method, like the first, returns the most stringent of the releasability instractions and thus 
defines the releasability for the data of a given emitter when the data are considered in the 
conq)o^e. The method parametric update searches throu^ all the class attributes in 
the database for a given emitter and returns the latest data update date. The effect is an 
EWIRDB ADMINISTRATIVE DATA class that describes the con 5 )Osite EMITTER 
class of objects. EWIRDB ADMINISTRA'nVE DATA therefore partic^ates in a 1:1 
relationship with EWIR EMITTER. And like the source-q)ecific administrative data 
classes, its participation in the relationship is total. 

Ih Figure 8, the attribute ELNOT in the EMITTER class is a kind of social 
security number for emitters. It uniquely identifies an emitter, or more precisely, the signal 
that is characteristic of an emitter. ELNOT is an important attribute because it is the 
primary means of emitter identification, and may often be the launch point for EWIRDB 
queries. The attribute color is an appropriate addition to EMITTER because it describes, 
in general, an emitter’s role in terms of fiiendly or hostile use. The choice of attribute 
values are “blue” for those emitters aboard US military platforms, “blue/gray” for those 
originally in US production that were legitimately transferred to Rest of World (ROW) 
cormtries (non-US, non-Communist), “gray” for emitters aboard non-Communist country 
platforms, and ‘Ved” for emitters produced by Communist countries [guide]. The attribute 
color thus provides a big picture look at an emitter. Because it is not a source-specific 
characteristic, it is best placed in the composite class. 

The global, object-oriented view of the EWIRBD presented in Figure 8 
incorporates all the data eluents contained in the SOO and SOI records in the TERF 
output. The S&TI Code foimd in SOI records (Figure 5) is included in both the S&TI 
ADMINISTRATIVE DATA and USNCSDB ADMINISTRATIVE DATA classes. It 
therefore applies to all assessed data encapsulated within an instantiation of S&TI 
EMITTER or USNCSDB EMITTER. The dupUcate S&TI Code entry found in S03 
records (Figure 5) is removed from any fiuther consideration. 


41 


Object-o rie ntation eliminat es the need for S02 branch information. The S02 data 
ftlpmftnt Technical Date (Figure 5), however, specific to Kilting emitter data, is included 
as a method in the KILTING ADMINKTRATIVE DATA class. Similar to the method 
parametric update, this method returns a date that indicates the latest update to emitter 
data, but applies to smaller, more specific groups of data. These groups are collections of 
generally related data elements, referred to in this thesis as logical groupings. Logical 
groupings are introduced in section B and elaborated in section C. 

The benefit of object-orientation is a more coherent and intuitive design. Now, for 
a given emitt er administrative and technical emitter data are encapsulated within the 
EMITTER class via aggregation, relationidiips, and inheritance. To this point in the 
conceptual deagn, particularly firom the administrative point of view, the presentation of 
data is clearer than that found in the parametric tree-TERF model. 

B. THE EMITTER SCHEMAS 

The next step in the development of the conceptual design focuses on the technical 
aspect of emitter data and addresses the data encapsulated within the classes KILTING 
EMHTER, S&TI EMIITER, and USNCSDB EMIITER. 

To reiterate, the conceptual designs presented m this section are based on portions 
of the EWIRDB. These portions are sufficiently representative of the entire database and 
accurately reflect the nature of EW data. Because the focus of this section is the overall 
organization of emitt er parametric data, the detail of object structure and behavior is 
omitted. (Specific class attributes are provided in Chapter V as part of the logical design.) 
This does not, however, take away from the intended semantics, and the schematics reveal 
the utility of the object-oriented approach in providing a unified and intuitive picture of 
emitter parametric data. 
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1. The Kilting Emitter Qass 

The overall configuration of the data encapsulated within the aggregate KILTING 
EMITTER class is depicted in Figure 9. An emitter object is not described as the 
composite of its coBcponent parts, ie., an aggregation. Modeled as an aggregation, the 
analy sis of con 5 )lex EW emitters could then be one of a hardware-oriented divide-and- 
conquer. An overall performance assessment could be made based on the intermediate 
results obtained in the evaluation of the hardware conq)onents. But the hardware 
conoponents themselves are not central to the discussion of EW. For the purposes of the 
EWIRDB, hardware conponents are only inportant in that they have some effect on, or 
participate in the generation oJ^ a given signal The signal itself is pivotal in the analysis - 
not the hardware. This is reflected in the design shown in Figure 9. Rather than being 
exposed hardware component by hardware component, the KILTING EMITTER class 
of objects is instead related to several logical groupings of data, all of which are signal- 
based in their descrption of emrtt^ performance. 

KILTING EMITTER particpates in a one to many relationship with 
ANTENNA, a class that encapsulates a logical grouping of antenna-signal data. A single 
emitter may contain one or more antennas, each of which may have a different function or 
produce a different effect on a agnal However, antenna hardware is not explicitly 
addressed within the antenna-data grouping. Modeling the relationshp between 
KILTING EMITTER and ANTENNA as one-to-many is not intended to treat this 
portion of EWIRDB data as hardware oriented, ahhou^ this may be a collateral effect. 
More inportant is the effect of any given antenna on an emitter’s signal The one-to-many 
relationship reflects the &ct that that there may be multple antennas, or multiple versions 
of antenna data for a particular emitter, dpending on the number of antennas and the 
availability of information on each. The antenna data grouping is given more detailed 
treatment in section C. 1. 
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F^ure 9. The Conceptual Schema: Kilting Emitter Data 


















KILTING EMITTER paitic^ates in a one-to-many relationship with the class 
SIGNAL, perhaps the most in:q)ortant grouping of data in identifying an emitter and its 
signal signature. The one-to-many relationship indicates that an emitter’s identifying 
signal is subject to variation. A change in the configuration of the emitter’s controls, for 
exan 5 )le, causes a variation in the signal. Therefore, an emitter’s signal may behave 
differently, with respect to fimdamental signal characteristics, depending on the 
en]ployment of the emitter. Signal characteristics are described in section C.2. 

KILTING EMITTER also participates in a one-to-many relationsh^ with the 
WARM (Wartime Reserve Mode) class, wiiich encapsulates those signal characteristics 
likely to be encountered only when an emitter is in a wartime reserve mode. A single 
emitter may have from zero to many such special modes. Wartime reserve modes are 
those emitter capabilities, deliberately held in reserve, that differ from or exceed normal- 
use capabilities. WARM’S are used exchiavely in emergency or wartime scenarios to 
counter attenq)ts to exploit the perceived weaknesses in an emitter’s performance. A 
sound assessment or a foreknowledge of the WARM’S eooployed by an enemy can be a 
huge advantage in the prosecution of EW. WARM data is therefore an in^ortant aspect 
of the EWIRDB. 

To provide for a sinQ)lified diagrammatic layout, the WARM class is surrounded 
by a circle to represent the existence of a digoint inheritance hierarchy. WARM data is 
examined more closely in section C.4. 

Finally, KILTING EMITTER objects have a one-to-one relationship with the 
SUFFIX TABLE class of objects. The su£Bx table as it currently exists in the EWIRDB 
describes con^lex emitter mode combinations in concise frshion. Knowledge of these 
combinations allow EWIRDB analysts to establish emitter performance patterns and mode 
usage tendencies. The suffix table is thus an mq)ortant tool that helps the analyst to 
discriruinate between signals and ultimately associate a signal to an emitter. It is examined 
more closely in section C.5. 
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2. The Association of an Emitter to its Signal 

Associating a unique signal to its emitter is a difficult modeling problem, object- 
oriented or otherwise. The assodation is characterized by an ELNOT that uniquely 
identifies an emit ter that is uniquely identified by its signal signature. (ELNOT is an 
attribute encapsulated within the EMITTER class shown in Figure 8.) More precisely, 
the ELNOT is “assigned to each noncommunications emission for collection guidance and 
reporting purposes.”[l] Thus, the uniqueness of the ELNOT, assigned to 
noncommunications emissions, inches a one-to-one relationship from signal to emitter, or 
equivalently from emitter to signal This modeling is easy to reason about in theory, but in 
application, hard to achieve. In Figure 9, the general organization of the parametric data 
describes an emitter by its signal attributes within the context of antenna-induced effects 
(ANTENNA DATA), signal characteristics in general (SIGNAL), reserve modes 
(WARM), and combinations of modes (SUFFIX TABLE). While this design provides a 
conq)rehensrve view of signal-based parametric data, the one-to-one nature of the 
relations!]^ between emitter and signal becomes obscaired. Although the data are more 
semantically meaningfirl when described within the logical groupings, tire effect is a 
partitioning of the data. Consequently, a relationsh^ must be developed between the 
emitter (KILTING EMITTER) and each partition. Several rektiondiips then exist to 
describe the relationship between emitters and signals. Not all, however, are one-to-one; 
KILTING EMITTER partic^ates in a one-to-many relationship with ANTENNA 
DATA, SIGNAL DATA, and WARM DATA. The end result is an association between 
an emitter and its signal, but the uniqueness of the relationship is directly modeled only 
throng the use of the ELNOT. The ability of an emitter to vary its signal characteristics - 
and effectively produce more than one signal - makes it more difficult to visualize the one- 
to-one nature of the relationsh^ between emitter and agnal, and therefore between 
ELNOT and emitter. The one-to-one relationsh^ remains intact, but is perhaps more 
id entifiab le because of the existence of the ELNOT. 
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3. The S&n and USNCSDB Emitter Oasses 


As discussed in Chapter I, the S&TI community produces performance 
assessments based on an e^diaustive search of all available hrformation. These assessments 
are particularly useM in developing an understanding of an emitter’s receiver capabilities. 
USNCSDB data, derived from equipment specifications, also includes receiver 
performance data. Similar in all other design aspects, the USNCSDB and S&TI 
conceptual designs shown in Figures 10 and 11 are the same. 

In contrast, the KILTING EMITTER schema in Figure 9 does not contain 
receiver data because Kilting data reveals nothing about receiver performance. Kilting 
data are obtained from the direct analysis and measurement of emitter signals following 
signal intercept. An emitter’s receiver, however, produces no obvious observable effect. 
The class RECEIVER, which encapsulates the logical grouping of receiver data in both 
Figures 10 and 11, is similar to the ANTENNA class in that the information it presents is 
inq)ortant in describing the effect of hardware on any given signal. RECEIVER, 
however, encapsulates data that tends to be more hardware-oriented. The receiver’s 
fimction is to accept a signal, process it, and then relay signal information to a display. 
A receiver’s man^ulation of a dgnal is strictly internal and does not dfrectly produce an 
effect that is visible in the atmosphere. The internal fimction of receivers in processing 
signal data is therefore best described within the context of hardware conqionents. 

The one-to-many relationsh^ between the emitter class and RECEIVER in 
Figures 10 and 11 convey the idea that an emitter may consist of one or more receivers. 
The receiver data grouping is given more detailed treatment in section C3. 


47 





Figure 10. The Conceptual Schema: S&TI Emitter Data 
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Figure 11. The Conceptual Schema: USNCSDB Emitter Data 
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C. THE SCHEMAS WITHIN LOGICAL GROUPS 


In this section 1 present a more detailed view of the data contained within the 
logical data groupings described in the previous section. Logical groi^ings, like the 
sub£Q.es that currentfy exist in the EWIRD, enconq)ass logically-related data elements. But 
the schemas depicted in this section reinforce the notion that the OODM provides for data 
semantics previously unachievable in the EWIRDB. Enq)hasis is placed on the schema 
design; con[q)lete technical descriptions of each data class are provided in [8] and [9]. 
Supplemental information is provided in [10] and [11]. 

1. Antenna Data 

Figure 12 is an enlargement of antenna-related signal data. It represents a 
substantial irr 5 )rovement over the semantically limited hierarchical tree representation of 
ant^ma data discussed in section LB.l.b. 

Specifically, an ant enna may exhibit a polarization and a particular radiation 
pattern, as described by the one-to-one relationship between ANTENNA and 
POLARIZATION, and by the one-to-one relationship between ANTENNA and 
RADIATION PATTERN. Two disjoint hierarchies branch out from the 
POLARIZATION class. One addresses the orientation of the electromagnetic wave, 
specializing the polarization as either linear or circular/elliptical. The other desaibes the 
variation of the polarization as either fixed or variable. Thus, using the tools of the 
OODM, the four possible polarization combinations - fixed-linear, fixed-circular/ell^tical, 
variable-linear, variable-drcular/elliptical - are captured intuitively in the schema. An 
antenna’s cross polarization characteristics are now correctly modeled in the one-to-one 
relationship between POLARIZATION and CROSS POLARIZATION. No longer are 
cross polarization characteristics confused with those that determine an antenna’s design 
wave orientation or its polarization variation properties. Moreover, access to data 
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concerning an antenna’s polarization also guarantees access to data concerning the 
antenna’s cross polarization, via the relationship. 

The same is now true for antenna data connected with the VARIABLE 
POLARIZATION class. The classes ADAPTIVE POLARIZATION, MANUAL 
POLARIZATION, and PERIODIC PROGRAMMED POLARIZATION in the 
hierarchies are clearly specializations, or types of variable polarization. The class 
POLARIZATION MODULATION, poshly mistaken for a type of variable 
polarization in the parametric tree model, is instead related to, and therefore descr^tive 
0^ VARIABLE POLARIZATION via the one-to-many relationsh^. 

The remainder of Figure 12 provides a straightforward representation of other 
aq)ects of an antenna’s functionality. An antenna may radiate directionally or 
omnidirectionally. If the antenna is directional, then it is associated with one or more 
scanning techniques. The antenna scan data is fiirther refined within the specialization’s 
subordinate to the mechanical and electronic scan classes. In addition, an electronically 
scaruning antenna may be controlled by one or more scan programs, and enq)loys a beam 
formation method to effect its scanning movement. A directional antenna also performs a 
tracking fimction, which may include simultaneous mechanical and electronic tracking. 
Finally, the features of electronic scanning are largely determined by one or more 
fimctional scan programs. 

Figure 12 represents some of the salient aspects of antenna data in a way that is 
understandable to both expert and novice. This depiction of antenna data, in the form of 
the OODM, is clearly superior to that of the arbitrary tree model. 

2. Signal Data 

Figure 13 depicts an enlargement of the logical grouping of signal data and 
addresses the conqjlexities of signal tr ansmis sion in a natural and intuitive way. The 
information contained in this grouping details fimdamental signal characteristics. 
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Figure 13. The Conceptual Schema: Signal Data Enlargement 
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Any given signal is generated with a certain power that is either constant or 
variable in nature. The object-oriented representation exactly matches these semantics. 
SIGNAL particq)ates in a one-to-one relationship with TRANSMISSION POWER, the 
generalization of the specialization classes, CONSTANT POWER and NOT 
CONSTANT POWER. The SIGNAL class is the root of the inheritance hierarchy that 
spawns the PULSED RE (Pulsed Radio Frequency) and CW (Continuous Wave) 
q>ecia]ization classes. PULSED RF is the basis of the conceptual schema in Figure 13; it 
is the starring point in the modeling of basic signal characteristics such as pulse duration, 
pulse amplitude, pulse repetition interval (PRI) and pulse group repetition interval (PGRI), 
and frequency (RF). (CW signal characteristics are represented within the class CW but 
are not examined any further.) 

For a given occurrence of PULSED RF there exists a one-to-one relationsh^ with 
the classes PULSE DURATION, PULSE AMPUTUDE, PRI/PGRI, and RF LINE 
STRUCTURE. These classes characterize in detail the nature of a given signal pulse. 
PULSED RF is a generalization class in the inheritance hierarchy that refines the 
description of a pulsed signal’s carrier firequency. The basis of specialization is the 
constancy of the carrier firequency. A given pulsed rignal therefore belongs to either the 
RF CONSTANT class or RF NOT CONSTANT class. A subordinate hierarchy rooted 
at RF NOT CONSTANT fiuther describes the nature of the variation in the carrier 
fi-equency. 

Objects in the classes PULSE DURATION and PULSE AMPLITUDE may be 
static or variable, as indicated by the specialization classes PD MODULATED and PA 
MODULATED, respectively. Both are single q)ecia]izations. for instance, an object 
of the class PULSE DURATION is not modulated, then there is no information outside 
of the class PULSE DURATION that is required to describe that object. If the intent is 
to desoibe a modulated p^llse duration, then additional or specialized data is required, and 
an object of class PD MODULATED would be instantiated. 
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Objects of the class PRI/PGRI belong to either the CONSTANT PRI/PGRI 
specialization class or the NOT CONSTANT PRI/PGRI, depending on the pulse-to- 
pulse changes in pulse interval A member of the NOT CONSTANT PRI/PGRI reflects 
interval changes that are either discrete or continuous. The classes DISCRETE and 
CONTINUOUS are themselves gen^alizations in overlapping inheritance hierarchies. 
Additionally, a pulsed signal t^^ose piilse repetition interval is not constant exhibits the 
characteristics of some type of interval scheduling control A one-to-one relationship 
therefore exists between NOT CONSTANT PRI/PGRI and the class INTERVAL 
SCHEDULING. An interval scheduling control induces one or more recurrent pulse 
repetition intervals. The schema therefore includes a one-to-many relationdi^ between 
INTERVAL SCHEDULING CONTROL and the class RECURRENT INTERVALS. 
The RECURRENT INTERVALS class is in 5 )ortant in its description of recurrent 
interval sequences; it may be thou^t of as a hi^er level abstraction for an arrangement of 
interval sequences. Moreover, it becomes meaningless as an abstraction without the 
existence of interval sequences. Viewed in this way, a mapping may be developed 
between recurrent interval an recurrent interval sequences. In Figure 13 this mapping is 
represented as a covering; cover class RECURRENT INTERVALS covers the member 
class RECURRENT INTERVAL SEQUENCES. 

3. Receiver Data 

Aggregation semantics model the hardware-orientation of the receiver data. In 
Figure 14, the class RECEIVER is the “outermost” conposhe in a nested aggregation 
wherein some of a receiver’s aggregates are themselves conq)osites that are conq)osed of 
aggregates. Objects that belong to the classes IF PREAMPLIFIER and IF 
AMPLIFIER, for exanq>le, are aggregates of objects of the class INTERMEDIATE 
FREQUENCY SECTION. Objects of the class INTERMEDIATE FREQUENCY 
SECTION are, in turn, aggregates of objects of the class RECEIVER. 
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Figure 14. The Conceptual Schema: Receiver Data Enlargement 
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Thus, RECEIVER represeats the sum total of all con^onents that function 
together to perform the receiver task. More precisely, receiver functionality and 
conq)onent functionality, not hardware, is the baas of the aggregation. The specifics of 
the hardware is in:q)ortant only in drawing boundaries between functional sections of 
conoponents that are common to all receivers. And despite hardware diflferences, all 
receivers may be modeled in this way because of a similar fimctionality. This is a logical 
and natural representation of the data. The receiver portion of an emitter may now be 
reasoned about in general terms as a singular miit and, or exposed in more detail as the 
aggregation, or nested aggregation, of distinct functional sections. 

Many of the actions performed by a receiver are described as either single pulse 
processing or mult^le pulse processing. These labels can be assigned to receiver 
processes, within the setting of aggregation semantics, as shown in Figure 13. In the 
schema, applicable object classes participate in one-to-one relationdiips with SINGLE 
PULSE PROCESSING objects or MULTIPLE PULSE PROCESSING objects. 
However, both the SINGLE PULSE PROCESSING and MULTIPLE PULSE 
PROCESSING classes exist solely to provide the capability to access receiver-signal 
information from a single pulse/multiple pulse processing bias. Their primary purpose is 
navigational. These two classes are descr^tive of receiver data in name alone. 

Multiple one-to-one relationships originate from the SIGNAL PROCESSOR 
SECTION class. The other partic^ating classes - SPECIAL CAPABILITIES, 
DOPPLER PROCESSING, INTEGRATION, MOVING TGT INDICATION, TGT 
TRACKING, and THRESHOLDEVG/TGT DETECTION - encapsulate data that 
describe the functionality of a receiver’s agnal processor section. The choice to use 
reference relationsh^s instead of aggregation relationships is based on the composition of 
the EWIRDB data. In general, as signal procesang is addressed with an increasing level 
of detail with respect to fimctionality, hardware differences among receivers tends to 
become more pronoimced. In other words, as the granularity of data increases, receivers 
may still be described in terms of co mmo n functionality, but tend to be less alike in 
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hardware. Functionality is therefore less prone to be cast in the hght of hardware as the 
data become more detailed. The other classes are not so much parts of SIGNAL 
PROCESSOR SECTION as they are descriptors of the types of actions performed in 
that section. Aggregation semantics become less applicable; reference relationsh4)S better 
model the nature of this interaction. 

4. WARM Data 

The design of Figure 15 echoes previously introduced elements of the conceptual 
schema. For exan 5 )le, the class POWER ECCM partic4)ates in a one-to-many 
rela rinusbip with TRANSMISSION POWER from Figure 12. As will be found in the 
logical deagn, this relationsh^ indicates that a WARM mode affecting signal power, or an 
object of the class POWER ECCM, is essentially a new mstantiation of the class 
TRANSMISSION POWER. WARM modes that are not variations of existing data 
classes fall within the class OPERATIONAL ECCM. 

The inheritance hierarchy in Figure 15 is digoint; any given object of the WARM 
class is a member of only one ^eciahzation class. However, an emitter may exhibit 
multiple WARM modes, as modeled in the one-to-many relationships between the classes 
KILTING EMnTER and WARM, S&TI EMITTER and WARM, and USNCSDB 
EMITTER and WARM. 

This approach to the modeling of WARM data does away with the need to 
account for the Reserve Mode entry found in SOS records (Figure 5). 


D. THE PARAMETRIC DATA CLASS 

As discussed in section HI.A l.b, conq)lex attributes support objects as attribute 
values. Therefore, in the case of complex attributes, the “type” ofa given attribute is 


58 




59 










equivalent to the particular object class from which that object value was instantiated. 
Further, conoplex attributes may reflect an arbitrarily deq) or recursive nesting of objects. 

All con:q)lex attributes in the object-oriented design of EWIRDB, regardless of the 
depth of nesting, ultimately lead to objects of the class PARAMETRIC DATA, the focus 
of this section. The PARAMETRIC DATA class itself ejdubits a nesting of objects that 
incorporates the semantically-usefijl data elements of the SOS, S04, and SOS records. 

The PARAMETRIC DATA class and the data encapsulated therein is depicted in 
Figure 16. TEXTUAL DATA and NUMERIC DATA are specializations of 
PARAMETRIC DATA, and intuitively indicate whether the parametric data entry for a 
given attribute is text-based or numerical. Numerical parametric data are either single- 
valued or range-valued as e7q)ressed in the specialization classes SPECIFIC VALUE and 
VALUE RANGE. 

In the EWIRDB, comments are used to further characterize parametric data 
values. PARAMETRIC DATA thus participates in one-to-one relationship with the 
class DATA COMMENT. The participation of DATA COMMENT in the relationship 
is total; a parametric data entry must first exist before a corresponding comment can be 
made, but not all parametric data entries must be commented. If a parameter is assessed, 
then a related comment must also include the comment classification. This is depicted in 
the specialization class ASSESSED DATA COMMENT. Comment data and the 
inheritance hierarchy directly subordinate to the PARAMETRIC DATA class are 
enclosed within the dotted line in Figure 16. Together they constitute the core of 
EWIRDB parametric data. 

On the global scale, each emitter is linked to emitter-specific administrative data; 
on a smaller scale, each class attribute is associated with the attribute-specific 
administrative data associated with the S03, S04, and SOS records. The attribute-specific 
a dminis trative data identifies data references and highlights iixportant descriptive 
information. As indicated in Figure 15, the format of this data is source-dependent. 
ORIGINAL SOURCE DOCUMENTATION includes those attributes conamon to both 
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Figure 16. The Conceptual Schema: Parametric Data 
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formats, report classification and report releasability. Formatting distinctions are made 
within the specialization classes ASSESSED REFERENCE and OBSERVED 
REFERENCE. Attribute values are further characterized in the DATA DESCRBPTION 
class by date of last update. ( The method parametric update date in the class 
EWIRDB ADMINISTRATIVE DATA (Figure 9) accesses date of last update 
information throu^out the database and returns the most recent value for a given 
emitter.) Source-dq)endent characteristics that generally describe the soundness and 
accuracy of a given attribute value are addressed in the specialization classes ASSESSED 
DATA and OBSERVED DATA. 

Two methods are specified in the PARAMETRIC DATA class: return all data 
and return parametric data. For a given attribute, return all data will reply with all 
available data - the actual parametric data as well as the associated administrative data, 
return parametric data will yield only the data enclosed within the dotted line m Figure 
15 for a given attribute. One attribute is specified as well, suffix code, a label for the 
given attribute as it appears in the sufiBx table. 

Thus, all usefiil data items from the SOS, S04, and SOS records, with the exception 
of sufiObc table information, are nested within the PARAMETRIC DATA class of Figure 
15. Object-orientation elimin ates the need for many previously maintained data items 
listed in Figure 5. Tree Number, wfrich provides indexing into the parametric tree is no 
longer required. Linking-type entries related to the format of the output file - Reference 
Number (SOS), Comment Number (SOS), Reference Number (S04), Reference Line 
Number, Comment Number (SOS), and Comment Line Number - are eliminated. Finally, 
the &itsy Measurement Name (SOS) is replaced by the attribute name itself 

At this point, aU meaningfiil data entries of the TERF have been integrated into 
one conq>rehensive, encapsulated model. 
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E. SUFFIX CODING AM) THE SUFFIX TABLE 

EWIRDB suffix-coded data and the suffix table representation of data conq)rise 
the most difficult modeling task in the conceptual design. Suffix coding is incorporated 
within the EWIRDB to describe the vast array of mode combinations an emitter may 
e^diibit. In effect, suffbc-coding links together the parametric values that characterize 
known or suspected emitter usage. A particular combination of parametric values defines 
a given mode; suffbc coding and suffix table thus provide the means for establishing 
relationsh^s between parametric values throughout the database. (A con^rehensive 
review of sufiBx coding and the suffix table is provided in [1].) 

Herein lies the complexity in modeling modal relationships. Parametric values are 
synonymous with attribute values. The attributes whose values describe a given mode are 
likely interspersed throu^out the many classes in the schema. The relationships defined 
by suffix coding and the sufiSx table therefore describe associations between attributes — 
not classes. An additional conoplication is the possibility of multiple values (multiple 
instantiations of the object that contains the attribute) each for a given attribute. Modeling 
modal (attribute) relationsh^s is difficult because neither the OODM, nor any other data 
model, e?qplicitly supports such a capability. From a modeling perfective, the problem of 
representing modal relationshf s such as those foimd in the suffk table reduces to problem 
of representing attribute-to-attribute relationships and attiibute-to-attribute combinations. 

Upgrading each attribute to a class is an ineffective solution. Related attributes are 
grouped into classes for the purpose of collectively describing the characteristics of a 
particular set of objects. The transformation of attribute to class obscures these semantics; 
each attribute instead becomes a reference within a given class. Moreover, the problem of 
modeling combinations remains unsolved. There exists no “built-in” OODM mechanism 
for the purpose of defining combinations of objects, not to mention attributes, throughout 
a schema. 

The process of defining modal combinations, regardless of the modeling tool used, 
is formidable in the realization that an emitter could likely exhibit hrmdreds of thousands 
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of inodes. Object-orientation does not appear to sinqilify this task. Despite its 
dependence on an artificial labeling system and a non-intuitive table representation, sufSx 
coding has provea to be effective in this combination-oriaited modeling. Moreover, it 
helps to link signal signatures to emitters. At present, I am unable to offer an easier or 
more viable modeling ahemative. The current methodology is therefore incorporated into 
the object-oriented conceptual design. 

The conceptual schema includes a sufBx code entry for every attribute throughout 
the schema; a s uffix code entry can be made fiir every attribute in each instantiation of the 
object to which the attribute belongs. This provides for the same modeling flexibility as 
exists in the current model: the binding together of related parameters, the labeling of 
multiple values for a given attribute, and the inclusion of sufBx-coded data within the 
SUFFIX TABLE class of objects (Figures 9, 10, 11) to develop modal combinations. 
SUFFIX TABLE objects would also contain a method, expand table (not shown), to 
return all combinations represented in the suffix-coded data table. 

In the object-oriented design, the use of the special suffix codes is no longer useftil. 
The semantics of the special suffix code, ++, used to indicate that a particular parametric 
value is present in all modes, may be addressed via comment in the DATA COMMENT 
class (Figure 15). The special code, //, applies specifically to the parametric tree structure 
and indicates that a given value pertains to all modes described within the subtree rooted 
at the branch containing the ^edal code. Such semantics are in^hcit hi inheritance and 
aggregation hierarchies, and may be explicitly addressed via comment. 

This con 5 )letes the conceptual design phase. The next stage in the overall design 
process is the logical design, addressed in Chapter V. 


64 



V. A LOGICAL OBJECT-ORIENTED EWIRDB 


The O-ODDL native to the M^DBS in the NFS Laboratory for Database Systems 
Research provides the structure of the logical design presented in this chapter. The O- 
ODDL, designed and q)ecified in [12], thus provides the means to convert the concq)tual 
database as proposed in Chapter IV into an M^DBS-conopatible representation. 

Still in its first phase of development, the object-oriented interface to the M^DBS 
is fimctional but does not yet support all aspects of the object-oriented paradigm. To 
date, methods and the aggregation abstraction are not in:q)lementable on the M^DBS. 
Therefore, in the logical design, aggregation will be represented via relationships, and 
methods will not be addressed. 

It is not necessary to address all aspects of the conceptual schema in the logical 
design to demonstrate the operation of the M^DBS object-oriented interfece in handling 
EWIRDB data. To this end, I address a representative portion of the conceptual schema 
in developing the logical design. The subsequent inq)lementation of the logical schema on 
the M^DBS is a continuation of the work in this thesis, and is addressed in [13, 
unpublished]. The final result of this combined effort will be an on-line object-oriented 
EWIRDB with which to demonstrate both the utility of the new M^DBS object-oriented 
inter&ce, and the usefulness of the new object-oriented EWIRDB design. 

The O-ODDL logical design constructs are reproduced in Figures 17 through 20. 
Refer to [12] for a con^rehensrve discussion of the O-ODDL specification. 

In Figure 17, “attribute type” refers to the traditional notion of attribute domain. 
As described earlier in sections HI. A l.a and b, the domain or type of an attribute may be 
sin:q)le, characterized by literal attribute values, or the type may be conqilex, characterized 
by object attribute values. Complex attributes can therefore exhibit an arbitrarily deep 
nesting of objects. Whereas a smq)le attribute may be of type “character” or “integer”, the 
type of a corqplex (or reference) attribute is a class. The class defines the legal attribute 
values (object values) for the given attribute. 
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Figures 18 and 19 contain the ^ecdfications for the inheritance and covering 
abstractions. In Figure 20, one-to-many and many-to-many relationships are addressed. 
One-to-many (1;N) relationsh^s between object classes are represented via the set_of 
construct. set_of appears within the class on the “1” side of the relationsh^; an attribute 
that references the class on the “1” side of the relationship appears within the class on the 
“N” side of the relationship. Many-to-many (N:M) relationships are represented with the 
set_of (N side) and inverse_of (M side) constructs. One-to-one (1:1) relationships are 
represented directly through use of reference attributes. The classes in the 1:1 relationship 
each contain an attribute whose type is that of the class to which it is associated via the 
1:1 relation^p. 


Oass Class name { 

attribute_typei attribute_namei; 
attributejypea attribute namea; 

attributejypen attribute namen 

}; 

Figure 17. The O-ODDL Oass Specification 


Oass Classjiame Xl : inherit Class_name_X{ 
attribute typei attribute_namei; 
attribute_type 2 attribute_name 2 ; 


attribute typen attribute_namen 

}; 


Figure 18. The O-ODDL Inheritance Specification 
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Oass Class_name_Xl : cover Class_name_X{ 
attribute_typei attribute namei; 
attribute_type 2 attribute namez. 


attribute_type„ attribute_name„ 

}; 


Figgie 19. The O-ODDL Cover Specification 


set_of Classjiame attribute_nanie; 

inverse_of C/as5_«awe.attribute_name attiibute_name; 


Figure 20. The O-ODDL Set_of and Inverse_of Specifications 

The logical design incorporates the O-ODDL constructs as outlined in Figures 21 
throu^ 29. Because all con 5 )lex attributes in the object-oriented design of EWIRDB, 
ultimately lead to objects of type PARAMETRIC DATA (section IV.D), the logical 
design begins with the O-ODDL representation of PARAMETRIC DATA in Figure 21. 
The design then proceeds with the classes EMITTER (Figure 22), KILTING 
EMITTER and KILTING ADMINISTRATIVE DATA (Figure 23), ANTENNA 
(Figure 24), SIGNAL (Figure 25), RECEIVER (Figure 26), WARM (Figure 27), 
SUFFIX TABLE (Figure 28) and S&TI EMITTER and S&TI ADMENISTRATTVE 
DATA (Figure 29). 
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class Parametric J^ata{ 
char* 

DataJ3omment 

DataDescript 

set of Orig Src Doc, 

}; 

sufl5x_code; 

comments; 

description; 

references; 

class Textual Data: inherit ParametricJData { 

char* 

}; 

text; 

c\zss Numeric Data : inherit Parametric Data { 

char* 

}; 

units; 

class SpecificJValue : inherit Numeric_Data{ 

char* 

}; 

value; 

class Value_Range : inherit Numeric_Data{ 

char* 

uppervahie; 

char* 

}; 

lowervalue; 

class DataJZomment { 


char* 

comment_text; 

Parametric Data 

}; 

parametricdata; 

class Assess Comment: inherit Data_Comment { 

char* 

com classif; 

}; 



F^ure 21. The Logical Design: DDL Implementation of the 

PAR4METRIC DATA Class (cont’d into next page) 
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class Data_pescrip { 

char* lastupdate; 

Parametric Data para data; 

}; 

class Assessed Data : 

inherit Data_Descrip{ 

char* 

confidence_level; 

char* 

classification; 

char* 

}; 

releasability; 

class ObservedJData: 

: inherit Data_Descrip{ 

char* 

meas accuracy; 

char* 

measaccunits; 

char* 

intel_source; 

int 

}; 

preferrating; 

class Orig_Src_Doc { 

char* 

rptclassif; 

char* 

iptrelease; 

inverse of Parametric iDato.references p data; 

}; 

class Assessed_Ref : inherit Orig_Src_poc { 

char* 

}; 

referencetext; 

class Observed_Ref : inherit Orig_Src_Doc { 

char* 

document number; 

char* 

documenttitle; 

char* 

reportdate; 

char* 

producer; 

char* 

}; 

reportclassification; 


Figure 21. (cont’d) The Logical Design: DDL Implementation of 
the PARAMETRIC DATA Oass 
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class Emitter{ 


char* 

elnot; 

char* 

color; 

Kilting Emitter 

kilting data; 

S&TI Emitter 

s_and_ti_(iata; 

}; 



Figure 22. The Logical Design: DDL Implementation of the 
EMITTER Class 


class Kilting Emitter { 


char* 

technicaldate; 

KiltingAdmin 

kadmindata; 

set_of Antenna 

antennadata; 

set_of Signal 

signaldata; 

set_of Receiver 

receiver_data; 

set of WARM 

warresmodes; 

Suffix_Table 

modes; 

Parametric_Data 

weapon_system; 

Parametric Data 

function; 

ParametricJData 

platform; 

Emitter 

}; 

generaldata; 

class Kilting_Admin{ 


char* 

nsadate; 

char* 

saecode; 

char* 

datesigchange; 

char* 

kclassification; 

char* 

}; 

kreleasabihty; 


Figure 23. The Logical Design: DDL Implementation of the 
KILTING EMTITER and KILTING 
ADMINISTRATIVE DATA Classes 
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class Antenna{ 

ParametricJ^ata 
ParametricJ^ata 
Parametric_pata 
ParametricJ)ata 
Polarization 
RadiationPattem 

Kilting Emitter 

}; 

antennatype; 

antenna_fimction; 

horizontaldimension; 

verticaldimension; 

ant_polarization; 

antradchar; 

kilt_eniitter; 

class Polarization^ 

Cross ^Polarization 

cross_pol_char; 

Antenna 

}; 

antenna; 

class Cross_Polarization{ 

ParametricJ^ata 

patt_pk_ofifeet; 

Parametric_Data 

pattjpkjresp; 

Polarization 

polarization; }; 

class Linear JPolarization : inherit Polarization{ 

Parametric_Data 

}; 

inajor_axis_tilt_angle; 

class Circ_or_ElliptJPolarization: 

inherit Polarization^ 

Parametric_Data 

sense; 

Parametric Data 

axial_ratio; 

}; 


Figure 24. The Logical Design: DDL Implementation of the 
ANTENNA Class (cont’d into next page) 
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class Radiation_Pattem{ 
ParametricJData 

Antenna 

}; 

antenaa_gain; 

ant; 

class Directional Ant : inherit Radiation_Pattem{ 

Parametric Data 

beaniwidth_az; 

Parametric Data 

beamwidthel; 

Parametric Data 

first sidelobe M az; 

Parametric_Pata 

first_sidelobe_M_el; 

set_of Scan 

scanningchar; 

set of Track 

trackingchar; 

}; 


class Omnidirectional : inherit Radiation_Pattem{ 

Parametric_pata 


elevation coverage angle; 

}; 


class Scan{ 


Parametric Data 

san 5 )le_avg_time; 

Parametric Data 

SNR._threshold; 

Parametric Data 

planeo^scan; 

Directional Ant 

}; 

dirantenna; 

class Mechanical^can : inherit Scan{ 

Parametric_pata 

typechange; 

Parametric Data 

scan function; 

}; 



class Circular: inherit Mechanical_Scan{ 

Parametric_pata cperiodlimits; 

}; 


Figure 24. (cont’d) The Logical Design: DDL Implementation of 
the ANTENNA Qass (cont’d into next page) 


72 







class Sector: iDhtrit Mechariical_Scan{ 


Parametric Data 

sectortype; 

Parametric Data 

speriodjimits; 

ParametricJ)ata 

sector width az; 

Parametric Data 

sector width el; 

}; 


class Track{ 


Parametric Data 

planeo^scan; 

Directional Ant 

}; 

direct_ant; 


class MechJTracking : inherit Track{ 
Parametric_Data 
autotrackjmaxrateaz; 
Parametric_pata 
autotrackmaxrateel; 


F^ure 24. (cont’d) The Logical Design: DDL Implementation of 
the ANTENNA Class 
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class Signal { 

TransJPower 

Kilting Emitter 

}; 

signal_pwr; 

k_emitter; 

class Trans_Pawer{ 


Parametric Data 

line loss on tx; 

ParametricJ^ata 

pk_pvvr efl^rad; 

Parametric_pata 

pkjjwrattrans; 

Signal 

}; 

signal; 

class Constant Power : inherit Transmission_Power{ 

Parametric Data 

}; 

timetoswitch; 

class NotConstant_Power : inherit Transmission_Pawer{ 

Parametric Data 

maxjrateo^change; 

y. 


class Pulsed_RF : inherit Signal{ 


RF Line Structure 

coherence; 

Pulse Duration 

pnlselength; 

PRI/PGRI 

piilse^groups; 

y 


class RF_Line_Structure{ 


Parametric_Data 

3_db_spec_width; 

ParametricJData 

transtype; 

Pulsed RF 

}; 

ilQ)iilse; 


Figure 25. The Logical Design: DDL Implementation of the 
SIGNAL Qass (cont’d into next page) 
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class Pulse_Duration{ 

Parametric_pata 
Parametric Data 

Pulsed RF 

}; 

pulsedurlim; 

pd_most_prob; 

pulse; 

fAas,%PD_Modulated : uiheTit Pulse Duration{ 

Parametric Data 

deyjinnts; 

Parametric Data 

}; 

modulation_rate; 

class RF Constant : inherit Pulsed RF{ 

Parametric_pata 

ifjhnits; 

Parametric Data 

}; 

most_prob_if; 

class RF Not Constant : inherit Pulsed RF{ 

}; 


tAASsModon_Pulse : vBiheritRFNotconstant{ 

Parametric Data 

}; 

ifjnodchange; 

class PMOP: mhxxiXMod on Pulse{ 

Parametric Data 

rf limits; 

Parametric Data 

}; 

phase_shift; 

class FMOP: iBi\icritMod_on_Pulse{ 

Parametric_pata 

jEbiop rf limits; 

ParametricJ^ata 

fi:eq_excursion; 


}; 


Figure 25. (cont’d) The Logical Design: DDL Implementation of 
the SIGNAL Oass (cont’d into next page) 


75 









class Pulsed Agility : inherit RFJ^ot_constant{ 

Parametric_Pata 

agil_fiuic_coir; 

Parametric Data 

}; 

mod_waveform; 

class Cont_Agility : inherit Pulsed_Agility{ 


Parametric Data 

}; 

r^limits; 

class : \sihtritPulsed_Agility{ 


Parametric Data 

rfjimits; 

Parametric Data 

no_disc_steps; 

}; 


class PRI{ 


Parametric Data 

meas bandwidth; 

Pulsed RF 

rf; 

}; 


class Not_Comt_PRI : inherit PRI{ 


Parametric_pata 

modulationtype; 

Intvl Sked 

}; 

mterval_cntrl; 

class Intvl_Sked{ 


ParametricJData 

duty_cycle; 

set o{ Recurrent Intvl 

intervals; 

); 



Figure 25. (cont’d) The Logical Des^n: DDL Implementation of 
the SIGNAL Oass 
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class Recurrent_Intvl{ 
ParametricJ)ata 
Intvl Sked 

}; 

nbr_dscrete_int; 

sked_control; 

class Recur_Intvl_Seq : cover 
Parametric Data 

}; 

RecurrentJ.ntvl{ 

sequencel; 

-----1 

Figure 25. (cont’d) The Logical Design: DDL Implementation of 
the SIGNAL Gldss 

class Receiver { 

Parametric_Data 

SigProcSect 

A_D_Conv_Sect 

S&TI Emitter 

}; 

receivertype; 
sig processor: 
a_d_section; 
s_enntter; 

class Sig Proc Sect { 

Doppler_Processing 
Receiver 

}; 

dopproc; 

receiver; 

class Doppler Processing { 
ParametricJ^ata 
Parametric_Data 

Sig Proc Sect 

}; 

cohjproc_intrvl; 

pulses_in_cpi; 

processor 


Figure 26. The Logical Design: DDL Implementation of the 
RECEIVER Qass (cont’d into next page) 
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class WARM{ 

char* prob_code; 

Kilting_Emitter kilt_eimt; 

}; 


class Power_ECCM : inherit WARM{ 
set_of Tram Power 

res_pwrjtnode; 

}; 


class Polar ECCM: inherit WARM{ 
set of Polarization 

}; 

res_polar_mode; 

class Ant_Scan_ECCM : inherit WARM{ 
set of Scan 

}; 

res_scan._mode; 

class Sig_Shape_ECCM: inherit WARM{ 
set of Pulse Duration 

}; 

resjpd_mode; 

class RF_ECCM\ inherit WARM{ 
set of Pulsed RF 

}; 

resjtfmode; 


Figure 27. The Logical Des^n: DDL Implementation of the 
WARM Class 
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class Suffix_Table{ 


char* 

}; 

modematrix; 


F^ure 28. The Logical Design: DDL Implementation of the 
SUFFIX TABLE Oass 


class S&TJ_Emitter{ 


S&TI Admin 

kadmindata; 

set of Antenna 

aiiteima_data; 

set_of Signal 

signaldata; 

set_of Receiver 

receiver_data; 

set of WARM 

warresmodes; 

Suffix_Table 

modes; 

Parametric Data 

weaponsystem; 

Parametric_pata 

function; 

Parametric_Data 

platform; 

Emitter 

}; 

general_data; 

class S&TI_Admin { 


char* 

s&ti_code; 

char* 

mult_src_review; 

char* 

sclassification; 

char* 

}; 

sreleasabihty; 


Figure 29. The Logical Design: DDL Implementation of the 
S&TI EMITTER and S&TI ADMINISTRATIVE 
DATA Classes 
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The effect of the object-oriented logical design is profound. Now, all available 
data for a given emitter, both technical and administrative, is contained within an object of 
the class EMITTER. This effect is achieved via the nesting of objects within the 
ffamework of relationships, inheritances, and a covering. 

EMITTER contains complex (reference) attributes (object values) of type 
PARAMETRIC DATA, and also contains references to source-specific emitter data 
objects of type KILTING EMITTER and S&TI EMITTER. KILTING EMITTER 
and S&TI EMITTER objects likewise contain attributes of type PARAMETRIC 
DATA, and attributes that reference analogous administrative data objects. These 
administrative data objects contain simple-valued, source-specific attributes corre^onding 
to SOO, SOI, and S02 record data. The KILTING EMITTER and S&TI EMITTER 
objects additionally encapsulate antenna data, signal data, receiver data, WARM data, and 
suffix table objects. (Suffix table objects correspond to SOS record data). The attributes 
within each of these objects, in turn, are either of type PARAMETRIC DATA, or e^dubit 
a nesting of objects that ultimately lead to attributes of type PARAMETRIC DATA. 

Finally, attributes of type PARAMETRIC DATA exhibit a nesting of objects that 
leads to single parametric values and ample parametric-vahie-related admunistrative data. 
All such information corresponds to S03 record data. 

The overall result is a cohesive, encapsulated, and conprehensive logical schema 
of EWIRDB data. 
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VL CONCLUSION 


The EWIRDB is a vitally in^ortant instrument of EW and EW research and 
development, containing up-to-date and mission-critical performance data on the EW 
systems of fiiendly and hostile forces. Its utilization in the areas of battle planning and 
EW research he^s to shape the outcome of war. The usefulness of the EWIRDB, 
however, is hanopered by its cumbersome data model, the basis of vshich is an inherently 
arbitrary parametric tree structure. The inconsistencies that exist among the data as 
modeled in the parametric tree and the data as addressed in the record-based output jSle 
further obscure the intended semantics. The overall data representation is non-intuitive, 
disjoint, and dMcuh to conq)rehend. The burden of data interpretation is transferred to 
the user, and the user must deal at length with formatting and coding issues. 

In this thesis, I have proposed an alternative and inproved representation of 
EWIRDB data. The design effort was centered on the development of a legitimate 
conceptual design, followed by development of a logical design suitable for 
inplementation on the M^DBS in the NPS Laboratory for Database Systems Research. 
The conceptual and logical designs are the first two phases in the overall database design 
and inplementation process. 

The conceptual design has yielded a conceptual schema that captured the nature of 
a rpresentative portion of EWIRDB data in a way that closely paralleled the user’s 
percption of the data. The basis of the conceptual design was the OODM, a powerftil 
modeling tool that enables the dedgner to reduce the semantic mismatch between real- 
world entities and their database representations. The OODM incorporates the concepts 
of objects, encapsulation, object classes, instantiation and classification, generalization and 
specialization, aggregation, and covering to achieve this end. The object-oriented 
conceptual design has captured both the technical and administrative semantics of EW 
data to a degree not previously achievable. This was the realization of the primary 
objective of the thesis. 
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In the logical design, I have mapped the object-oriented concq)tual schema to the 
object-oriented data model of the M^DBS. The mapping is accon^lished via the O- 
ODDL native to the M^DBS. The resulting O-ODDL statements constitute the logical 
schema; they are an M^DBS-readable specification of the conceptual schema. The O- 
ODDL provided for an arbitrarily deep nesting of objects within a framework of 
relationships, inheritance, and covering. The semantics of the data have been preserved in 
the mapping; w^ien in^lemented on the M^DBS, these semantics will be supported by the 
M^DBS. This is a huge benefit - the database user is thereafter relieved of the 
responsibility of data translation and interpretation. Although it does not yet support 
methods or aggregation, the O-ODDL provides for an intuitive, cohesive, and nested 
implementation of technical and administrative data. Therefore, the in:q)lementation is 
much improved over the coirplex record-based format that currently exists. 

The logical design portion of the this work provides input for the subsequent use 
atiH evaluation of the object-oriented interface to the M^DBS, and in this regard satisfies 
the secondary objective of the thesis. la due course, the logical schema will be 
inplemented on the M^DBS to produce an on-line object-oriented EWIRDB with vriiich 
to demonstrate both the utility of the new M^DBS object-oriented interfece and the 
usefiilness of the new object-oriented EWIRDB design. 

Object-orientation did not appear to simplify the formidable task of modeling 
emitter mode combinations, currentfy represented through use of suffix codes and suffix 
tables. For this reason, I retained the suffix code-suflSx table system in the designs 
presented in this thesis. Consequently, the use of this system comphcates the 
implementation of the database. In the object-oriented approach, however, a reliance on 
external software to inteifiice with suffix tables is unnecessary. Such manipulation may be 
achieved internal to the DBMS via methods. A true modeling solution may depend on the 
development of a data model that provides the flexibility to address attribute-to-attribute 
relationsh^s and combinations. 
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Overall, the conc^tual and logical designs developed in this thesis support and 
confirm the object-oriented approach as a viable solution to the modeling inadequacies of 
the present EWIRDB. 
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